From jbhateja at openjdk.java.net Mon Nov 1 17:01:24 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 1 Nov 2021 17:01:24 GMT Subject: [vectorIntrinsics+compress] RFR: 8276083: Incremental patch to further optimize new compress/expand APIs over X86 [v2] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 20:36:32 GMT, Paul Sandoz wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8276083: Review comments resolved. > > How did the perf tests get generated? I don't see any related changes to see how they would be generated. @PaulSandoz , your comments are addressed. Please let me know if there are further comments. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/157 From psandoz at openjdk.java.net Mon Nov 1 22:22:31 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 1 Nov 2021 22:22:31 GMT Subject: [vectorIntrinsics+compress] RFR: 8276083: Incremental patch to further optimize new compress/expand APIs over X86 [v2] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 20:36:32 GMT, Paul Sandoz wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8276083: Review comments resolved. > > How did the perf tests get generated? I don't see any related changes to see how they would be generated. > @PaulSandoz , your comments are addressed. Please let me know if there are further comments. Did you run `gen-tests.sh`? I tried running that on a clone of your branch and it generates more code, some of which does not compile: 1. `maskCompress` iterates over a non-existent array `a`. 2. Benchmarks for ROR and ROL are generated and the scalar benchmarks refer to non-existent methods `ROR_scalar` and `ROL_scalar`. 3. The gather/scatter benchmarks are deleted. So it looks like we got out on sync. We should fix the latter two in `vectorIntrinsics` so you can merge that in. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/157 From jbhateja at openjdk.java.net Tue Nov 2 04:31:10 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 2 Nov 2021 04:31:10 GMT Subject: [vectorIntrinsics+compress] RFR: 8276083: Incremental patch to further optimize new compress/expand APIs over X86 [v4] In-Reply-To: References: Message-ID: > Summary of changes: > 1) Added both scalar and vector variants of JMH performance tests for Vector.compress/expand and VectorMask.compress APIs. > > 2) Improved performance of operations where mask length is less than 4. Mask loading is a two stage process where in first the boolean array is loaded into a vector and then either transferred to a predicate register or a vector whose size is equivalent to that of underlined SPECIES. A mask whose length is less than 4 will result into a less than 32 bit vector load operation. Operations dependent on smaller masks are now being handled in java side implementation of these and some other APIs. Since the condition for special handling and fallback logic leading to C2 intrinsic call is based on constant expression hence one of the control path is optimized out. This shall also prevent any performance penalty due to failed lazy inline expansion which most often occurs due to unsupported vector sizes. If lazy inline expansion fails then C2 emits a direct call instruction to a callee method and thus we also loose any opportunity for procedure in-lining at that point, a separate [issue ](https://bugs.openjdk.java.net/browse/JDK-8276085)has been created to address this problem. > > 3) Improved performance of VectorMask.compress over legacy non-AVX512 targets, added the missing checks in C2Compiler::is_intrinsics_supported routine to enable procedure in-lining early during parsing if target does not support direct compress/expand instructions. > > 4) Inline expand VectorMask.intoArray operation to trigger boxing-unboxing optimization. This significantly improved the performance of VectorMask.compress in newly added JMH micros. > > Following is the performance data for included JMH micros: > System Configuration: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server 40C 2S) > > A) VectorMask.compress: > > ![image](https://user-images.githubusercontent.com/59989778/139234423-5c340da1-2fb1-4a21-b6d1-bb8b123b0a55.png) > > B) Vector.compress: > > ![image](https://user-images.githubusercontent.com/59989778/139234843-c3846b8d-dff0-4e9e-bf29-6b4dc556cd93.png) > > C) Vector.expand: > > ![image](https://user-images.githubusercontent.com/59989778/139234956-efad1c71-8425-4300-a8c6-c660855f5c58.png) > > Patch has been regressed using tier3 regressions at various AVX levels 0/1/2/3/KNL. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8276083: Correcting a typo in CompressExpand template file. ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/157/files - new: https://git.openjdk.java.net/panama-vector/pull/157/files/9417717f..f0edaeb8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=157&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=157&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-vector/pull/157.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/157/head:pull/157 PR: https://git.openjdk.java.net/panama-vector/pull/157 From jbhateja at openjdk.java.net Tue Nov 2 04:36:21 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 2 Nov 2021 04:36:21 GMT Subject: [vectorIntrinsics+compress] RFR: 8276083: Incremental patch to further optimize new compress/expand APIs over X86 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Nov 2021 22:19:46 GMT, Paul Sandoz wrote: >> How did the perf tests get generated? I don't see any related changes to see how they would be generated. > >> @PaulSandoz , your comments are addressed. Please let me know if there are further comments. > > Did you run `gen-tests.sh`? > > I tried running that on a clone of your branch and it generates more code, some of which does not compile: > > 1. `maskCompress` iterates over a non-existent array `a`. > 2. Benchmarks for ROR and ROL are generated and the scalar benchmarks refer to non-existent methods `ROR_scalar` and `ROL_scalar`. > 3. The gather/scatter benchmarks are deleted. (They got removed when i switched the scatter/gather unit tests over to the load/store files. See https://github.com/openjdk/jdk17/pull/48/) > > So it looks like we got out of sync, likely via merges from mainline. We should at least fix 2 and possibly reconsider how to do 3. > > @PaulSandoz , your comments are addressed. Please let me know if there are further comments. > > Did you run `gen-tests.sh`? > > I tried running that on a clone of your branch and it generates more code, some of which does not compile: > > 1. `maskCompress` iterates over a non-existent array `a`. > 2. Benchmarks for ROR and ROL are generated and the scalar benchmarks refer to non-existent methods `ROR_scalar` and `ROL_scalar`. > 3. The gather/scatter benchmarks are deleted. (They got removed when i switched the scatter/gather unit tests over to the load/store files. See [8266518: Refactor and expand scatter/gather tests?jdk17#48](https://github.com/openjdk/jdk17/pull/48)) > > So it looks like we got out of sync, likely via merges from mainline. We should at least fix 2 and possibly reconsider how to do 3. Hi @PaulSandoz , I have fixed 1 it was a typo, as already mentioned I did some manual editing since existing generation is broken. I will post the fixes for items 2 and 3 in a immediate subsequent patch once this gets integrated, changes in this patch are related to compress/expand and its performance improvements. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/157 From duke at openjdk.java.net Tue Nov 2 11:04:46 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Tue, 2 Nov 2021 11:04:46 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX Message-ID: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Hi, This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. Thank you very much. ------------- Commit messages: - missing assert - improve mask reduction operations Changes: https://git.openjdk.java.net/panama-vector/pull/158/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=158&range=00 Stats: 99 lines in 8 files changed: 52 ins; 22 del; 25 mod Patch: https://git.openjdk.java.net/panama-vector/pull/158.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/158/head:pull/158 PR: https://git.openjdk.java.net/panama-vector/pull/158 From psandoz at openjdk.java.net Tue Nov 2 15:46:34 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 2 Nov 2021 15:46:34 GMT Subject: [vectorIntrinsics+compress] RFR: 8276083: Incremental patch to further optimize new compress/expand APIs over X86 [v4] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 04:31:10 GMT, Jatin Bhateja wrote: >> Summary of changes: >> 1) Added both scalar and vector variants of JMH performance tests for Vector.compress/expand and VectorMask.compress APIs. >> >> 2) Improved performance of operations where mask length is less than 4. Mask loading is a two stage process where in first the boolean array is loaded into a vector and then either transferred to a predicate register or a vector whose size is equivalent to that of underlined SPECIES. A mask whose length is less than 4 will result into a less than 32 bit vector load operation. Operations dependent on smaller masks are now being handled in java side implementation of these and some other APIs. Since the condition for special handling and fallback logic leading to C2 intrinsic call is based on constant expression hence one of the control path is optimized out. This shall also prevent any performance penalty due to failed lazy inline expansion which most often occurs due to unsupported vector sizes. If lazy inline expansion fails then C2 emits a direct call instruction to a callee method and thus we also loose any opportunity for procedure in-lining at that point, a separate [issu e ](https://bugs.openjdk.java.net/browse/JDK-8276085)has been created to address this problem. >> >> 3) Improved performance of VectorMask.compress over legacy non-AVX512 targets, added the missing checks in C2Compiler::is_intrinsics_supported routine to enable procedure in-lining early during parsing if target does not support direct compress/expand instructions. >> >> 4) Inline expand VectorMask.intoArray operation to trigger boxing-unboxing optimization. This significantly improved the performance of VectorMask.compress in newly added JMH micros. >> >> Following is the performance data for included JMH micros: >> System Configuration: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server 40C 2S) >> >> A) VectorMask.compress: >> >> ![image](https://user-images.githubusercontent.com/59989778/139234423-5c340da1-2fb1-4a21-b6d1-bb8b123b0a55.png) >> >> B) Vector.compress: >> >> ![image](https://user-images.githubusercontent.com/59989778/139234843-c3846b8d-dff0-4e9e-bf29-6b4dc556cd93.png) >> >> C) Vector.expand: >> >> ![image](https://user-images.githubusercontent.com/59989778/139234956-efad1c71-8425-4300-a8c6-c660855f5c58.png) >> >> Patch has been regressed using tier3 regressions at various AVX levels 0/1/2/3/KNL. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8276083: Correcting a typo in CompressExpand template file. Yes, we can fix 2/3 separately independently of this branch. In fact i think for 3 we should consider a separate template like with the unit tests. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/157 From psandoz at openjdk.java.net Tue Nov 2 15:55:31 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 2 Nov 2021 15:55:31 GMT Subject: [vectorIntrinsics+compress] RFR: 8276083: Incremental patch to further optimize new compress/expand APIs over X86 [v4] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 04:31:10 GMT, Jatin Bhateja wrote: >> Summary of changes: >> 1) Added both scalar and vector variants of JMH performance tests for Vector.compress/expand and VectorMask.compress APIs. >> >> 2) Improved performance of operations where mask length is less than 4. Mask loading is a two stage process where in first the boolean array is loaded into a vector and then either transferred to a predicate register or a vector whose size is equivalent to that of underlined SPECIES. A mask whose length is less than 4 will result into a less than 32 bit vector load operation. Operations dependent on smaller masks are now being handled in java side implementation of these and some other APIs. Since the condition for special handling and fallback logic leading to C2 intrinsic call is based on constant expression hence one of the control path is optimized out. This shall also prevent any performance penalty due to failed lazy inline expansion which most often occurs due to unsupported vector sizes. If lazy inline expansion fails then C2 emits a direct call instruction to a callee method and thus we also loose any opportunity for procedure in-lining at that point, a separate [issu e ](https://bugs.openjdk.java.net/browse/JDK-8276085)has been created to address this problem. >> >> 3) Improved performance of VectorMask.compress over legacy non-AVX512 targets, added the missing checks in C2Compiler::is_intrinsics_supported routine to enable procedure in-lining early during parsing if target does not support direct compress/expand instructions. >> >> 4) Inline expand VectorMask.intoArray operation to trigger boxing-unboxing optimization. This significantly improved the performance of VectorMask.compress in newly added JMH micros. >> >> Following is the performance data for included JMH micros: >> System Configuration: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server 40C 2S) >> >> A) VectorMask.compress: >> >> ![image](https://user-images.githubusercontent.com/59989778/139234423-5c340da1-2fb1-4a21-b6d1-bb8b123b0a55.png) >> >> B) Vector.compress: >> >> ![image](https://user-images.githubusercontent.com/59989778/139234843-c3846b8d-dff0-4e9e-bf29-6b4dc556cd93.png) >> >> C) Vector.expand: >> >> ![image](https://user-images.githubusercontent.com/59989778/139234956-efad1c71-8425-4300-a8c6-c660855f5c58.png) >> >> Patch has been regressed using tier3 regressions at various AVX levels 0/1/2/3/KNL. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8276083: Correcting a typo in CompressExpand template file. Java changes are good. ------------- Marked as reviewed by psandoz (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/157 From psandoz at openjdk.java.net Tue Nov 2 16:02:29 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 2 Nov 2021 16:02:29 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX In-Reply-To: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Tue, 2 Nov 2021 10:58:19 GMT, Mai ??ng Qu?n Anh wrote: > Hi, > This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. > Thank you very much. Thanks, this will require review from engineers more knowledgeable than I on the x86 aspects and ARM aspects. IMO we cannot integrate until there is a plan for ARM either as part of this PR or a follow on PR. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From jvernee at openjdk.java.net Tue Nov 2 16:12:58 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 2 Nov 2021 16:12:58 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 8255903: Enable multi-register return values for native invokers Message-ID: Changeset: 818dcfc8 Author: Jorn Vernee Date: 2021-11-02 16:12:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/818dcfc8e7c0383efb3438a19fc7e24bfdbfcae7 8255903: Enable multi-register return values for native invokers Reviewed-by: mcimadamore ! src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp ! src/hotspot/cpu/aarch64/foreign_globals_aarch64.hpp ! src/hotspot/cpu/aarch64/universalNativeInvoker_aarch64.cpp ! src/hotspot/cpu/arm/universalNativeInvoker_arm.cpp ! src/hotspot/cpu/ppc/universalNativeInvoker_ppc.cpp ! src/hotspot/cpu/s390/universalNativeInvoker_s390.cpp ! src/hotspot/cpu/x86/foreign_globals_x86.cpp ! src/hotspot/cpu/x86/foreign_globals_x86.hpp ! src/hotspot/cpu/x86/universalNativeInvoker_x86_32.cpp ! src/hotspot/cpu/x86/universalNativeInvoker_x86_64.cpp ! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp ! src/hotspot/cpu/zero/universalNativeInvoker_zero.cpp ! src/hotspot/share/prims/foreign_globals.cpp ! src/hotspot/share/prims/foreign_globals.hpp ! src/hotspot/share/prims/nativeEntryPoint.cpp ! src/hotspot/share/prims/nativeLookup.cpp - src/hotspot/share/prims/universalNativeInvoker.cpp ! src/hotspot/share/prims/universalNativeInvoker.hpp ! src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ABIDescriptor.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequence.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Architecture.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/X86_64Architecture.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java ! test/jdk/java/foreign/TestFunctionDescriptor.java ! test/jdk/java/foreign/callarranger/TestAarch64CallArranger.java ! test/jdk/java/foreign/callarranger/TestSysVCallArranger.java ! test/jdk/java/foreign/callarranger/TestWindowsCallArranger.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/Upcalls.java From duke at openjdk.java.net Tue Nov 2 16:14:23 2021 From: duke at openjdk.java.net (duke) Date: Tue, 2 Nov 2021 16:14:23 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: Changeset: 818dcfc8 Author: Jorn Vernee Date: 2021-11-02 16:12:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/818dcfc8e7c0383efb3438a19fc7e24bfdbfcae7 8255903: Enable multi-register return values for native invokers Reviewed-by: mcimadamore ! src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp ! src/hotspot/cpu/aarch64/foreign_globals_aarch64.hpp ! src/hotspot/cpu/aarch64/universalNativeInvoker_aarch64.cpp ! src/hotspot/cpu/arm/universalNativeInvoker_arm.cpp ! src/hotspot/cpu/ppc/universalNativeInvoker_ppc.cpp ! src/hotspot/cpu/s390/universalNativeInvoker_s390.cpp ! src/hotspot/cpu/x86/foreign_globals_x86.cpp ! src/hotspot/cpu/x86/foreign_globals_x86.hpp ! src/hotspot/cpu/x86/universalNativeInvoker_x86_32.cpp ! src/hotspot/cpu/x86/universalNativeInvoker_x86_64.cpp ! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp ! src/hotspot/cpu/zero/universalNativeInvoker_zero.cpp ! src/hotspot/share/prims/foreign_globals.cpp ! src/hotspot/share/prims/foreign_globals.hpp ! src/hotspot/share/prims/nativeEntryPoint.cpp ! src/hotspot/share/prims/nativeLookup.cpp - src/hotspot/share/prims/universalNativeInvoker.cpp ! src/hotspot/share/prims/universalNativeInvoker.hpp ! src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ABIDescriptor.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequence.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Architecture.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/X86_64Architecture.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java ! test/jdk/java/foreign/TestFunctionDescriptor.java ! test/jdk/java/foreign/callarranger/TestAarch64CallArranger.java ! test/jdk/java/foreign/callarranger/TestSysVCallArranger.java ! test/jdk/java/foreign/callarranger/TestWindowsCallArranger.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/Upcalls.java Changeset: a73143f5 Author: duke Date: 2021-11-02 16:13:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a73143f53b18b708311ac66adee35ebfb169266d Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Tue Nov 2 16:16:34 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 2 Nov 2021 16:16:34 GMT Subject: [foreign-memaccess+abi] Integrated: 8255903: Enable multi-register return values for native invokers In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 13:15:39 GMT, Jorn Vernee wrote: > Hi, > > This patch implements support for multi-register returns in native invokers, and removes the buffered invocation strategy for downcalls. This is achieved, essentially, by using an in memory return: the caller allocates a bit of memory, and the native invoker stub writes the values of the return register to that memory. Then, the post processing code reads the register values back from there. > > Currently, the target address of a downcall is handled separately from the other arguments. I initially implemented passing the IMR address the same way, but I realized the removal of the buffered invocation strategy affords us a better way of doing things: we can just make the target address and the IMR address part of the normal calling sequence, and remove a bunch of special-casing code to handle these. We now just use a binding recipe to unbox these arguments and shuffle them into registers, and the ABIDescriptor tells the native invoker stub which registers to pick up these arguments from. > > Thanks, > Jorn This pull request has now been integrated. Changeset: 818dcfc8 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/818dcfc8e7c0383efb3438a19fc7e24bfdbfcae7 Stats: 1366 lines in 40 files changed: 432 ins; 632 del; 302 mod 8255903: Enable multi-register return values for native invokers Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/603 From duke at openjdk.java.net Tue Nov 2 16:22:22 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Tue, 2 Nov 2021 16:22:22 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX In-Reply-To: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Tue, 2 Nov 2021 10:58:19 GMT, Mai ??ng Qu?n Anh wrote: > Hi, > This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. > Thank you very much. Microbenchmark shows significant improvement on my AVX2 machine. Before: Benchmark Mode Cnt Score Error Units MaskReduction.byte128 avgt 25 0.773 ? 0.006 ns/op MaskReduction.byte256 avgt 25 0.778 ? 0.007 ns/op MaskReduction.int128 avgt 25 1.061 ? 0.008 ns/op MaskReduction.int256 avgt 25 1.553 ? 0.010 ns/op MaskReduction.long128 avgt 25 43.008 ? 0.354 ns/op MaskReduction.long256 avgt 25 1.271 ? 0.006 ns/op MaskReduction.short128 avgt 25 0.989 ? 0.006 ns/op MaskReduction.short256 avgt 25 0.919 ? 0.005 ns/op After: Benchmark Mode Cnt Score Error Units MaskReduction.byte128 avgt 25 0.566 ? 0.001 ns/op MaskReduction.byte256 avgt 25 0.556 ? 0.003 ns/op MaskReduction.int128 avgt 25 0.553 ? 0.003 ns/op MaskReduction.int256 avgt 25 0.828 ? 0.002 ns/op MaskReduction.long128 avgt 25 41.618 ? 0.241 ns/op MaskReduction.long256 avgt 25 0.552 ? 0.001 ns/op MaskReduction.short128 avgt 25 0.775 ? 0.004 ns/op MaskReduction.short256 avgt 25 0.834 ? 0.006 ns/op The benchmark simply loads 2 constant vector, compares them and returns the toLong of the result as follow: return BYTE_128_1.eq(BYTE_128_2).toLong(); ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Tue Nov 2 16:25:25 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Tue, 2 Nov 2021 16:25:25 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Tue, 2 Nov 2021 15:59:16 GMT, Paul Sandoz wrote: >> Hi, >> This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. >> Thank you very much. > > Thanks, this will require review from engineers more knowledgeable than I on the x86 aspects and ARM aspects. IMO we cannot integrate until there is a plan for ARM either as part of this PR or a follow on PR. Thank @PaulSandoz for the response, I hope this PR will be useful in the future. Besides, I found out that C2 fails with `Long128Vector`, even a simple operation of `LONG_128_1.eq(LONG_128_2)`, is this a known behaviour? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From psandoz at openjdk.java.net Tue Nov 2 16:39:25 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 2 Nov 2021 16:39:25 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Tue, 2 Nov 2021 16:22:24 GMT, Mai ??ng Qu?n Anh wrote: > Besides, I found out that C2 fails with `Long128Vector`, even a simple operation of `LONG_128_1.eq(LONG_128_2)`, is this a known behaviour? I was not aware of that, @jatin-bhateja might know more. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Wed Nov 3 07:55:57 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Wed, 3 Nov 2021 07:55:57 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v2] In-Reply-To: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: > Hi, > This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. > Thank you very much. Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: - fix last true - further improvement ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/158/files - new: https://git.openjdk.java.net/panama-vector/pull/158/files/1c36104b..4d0e7936 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=158&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=158&range=00-01 Stats: 48 lines in 3 files changed: 14 ins; 8 del; 26 mod Patch: https://git.openjdk.java.net/panama-vector/pull/158.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/158/head:pull/158 PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Wed Nov 3 08:02:25 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Wed, 3 Nov 2021 08:02:25 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v2] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Wed, 3 Nov 2021 07:55:57 GMT, Mai ??ng Qu?n Anh wrote: >> Hi, >> This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. >> Thank you very much. > > Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: > > - fix last true > - further improvement It seems that `Long128Vector` disappoints C2 due to the fact that C2 doesn't know how to box a vector mask of length 2, which in turn is due to `StoreVectorNode` currently don't accept vectors of size 2. I will submit a fix for this later. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From psandoz at openjdk.java.net Wed Nov 3 20:51:38 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 3 Nov 2021 20:51:38 GMT Subject: [vectorIntrinsics] RFR: Update perf tests. Message-ID: Update the perf tests by running the generation script. The generation was out of sync (due to merges from master) and generated code that failed to compile. As a consequence of moving the scatter/gather load/store unit tests to the load/store template the related vector performance tests are no longer generated, so they are removed. It's easier to remove the related scalar performance tests, then add back load/store performance tests using a specific template. ------------- Commit messages: - Update perf tests. Changes: https://git.openjdk.java.net/panama-vector/pull/159/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=159&range=00 Stats: 6770 lines in 39 files changed: 3932 ins; 2838 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/159.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/159/head:pull/159 PR: https://git.openjdk.java.net/panama-vector/pull/159 From sviswanathan at openjdk.java.net Wed Nov 3 22:32:29 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 3 Nov 2021 22:32:29 GMT Subject: [vectorIntrinsics] RFR: Update perf tests. In-Reply-To: References: Message-ID: <6Zd6ubnUuwkXZXNN2kBu6RkPJKpkPFASm3094d16svU=.6f34ae64-c629-461f-870f-ea1edcbbad45@github.com> On Wed, 3 Nov 2021 20:46:11 GMT, Paul Sandoz wrote: > Update the perf tests by running the generation script. > > The generation was out of sync (due to merges from master) and generated code that failed to compile. > > As a consequence of moving the scatter/gather load/store unit tests to the load/store template the related vector performance tests are no longer generated, so they are removed. It's easier to remove the related scalar performance tests, then add back load/store performance tests using a specific template. Looks good to me. ------------- Marked as reviewed by sviswanathan (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/159 From psandoz at openjdk.java.net Wed Nov 3 23:11:30 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 3 Nov 2021 23:11:30 GMT Subject: [vectorIntrinsics] Integrated: Update perf tests. In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 20:46:11 GMT, Paul Sandoz wrote: > Update the perf tests by running the generation script. > > The generation was out of sync (due to merges from master) and generated code that failed to compile. > > As a consequence of moving the scatter/gather load/store unit tests to the load/store template the related vector performance tests are no longer generated, so they are removed. It's easier to remove the related scalar performance tests, then add back load/store performance tests using a specific template. This pull request has now been integrated. Changeset: 83aaf148 Author: Paul Sandoz URL: https://git.openjdk.java.net/panama-vector/commit/83aaf148db60ce528f9154cbf931f690bccced88 Stats: 6770 lines in 39 files changed: 3932 ins; 2838 del; 0 mod Update perf tests. Reviewed-by: sviswanathan ------------- PR: https://git.openjdk.java.net/panama-vector/pull/159 From duke at openjdk.java.net Thu Nov 4 06:35:47 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Thu, 4 Nov 2021 06:35:47 GMT Subject: [vectorIntrinsics] RFR: VectorMask.intoArray intrinsics Message-ID: Hi, This small patch applies intrinsics for `VectorMask.intoArray`. This uses the existing `VectorSupport.store` with the signature changes similar to `VectorSupport.load`. `VectorMask.intoArray` implementation is moved to each concrete class, `VectorMask.toArray` implementation is changed similar to `Vector.toArray`, avoiding referring to `getBits`. In the hotspot, a small change is made to wrap the node in a `VectorStoreMask` node before passing it to `StoreVectorNode`, similar to how `VectorMask.fromArray` is handled there. Thank you very much. ------------- Commit messages: - move methods to concrete classes - intrinsics for VectorMask.toArray Changes: https://git.openjdk.java.net/panama-vector/pull/160/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=160&range=00 Stats: 425 lines in 35 files changed: 410 ins; 2 del; 13 mod Patch: https://git.openjdk.java.net/panama-vector/pull/160.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/160/head:pull/160 PR: https://git.openjdk.java.net/panama-vector/pull/160 From jvernee at openjdk.java.net Thu Nov 4 16:03:19 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 4 Nov 2021 16:03:19 GMT Subject: [foreign-memaccess+abi] RFR: 8276647: Remove C2 trivial call intrinsification support Message-ID: Hi, This patch removes the C2 support for trivial call intrinsification, which is currently unused. (see also the JBS issue for a brief discussion). Besides all the code that is removed by this patch, there is one 'logical' change as well: currently we are encoding `VMStorage[]` as `long[]` in `NativeEntryPoint::make`, but this is no longer needed, and I now can pass the `VMStorage[]` to native code directly. This allows removing the `vmstorage_to_vmreg` & `vmStorageToVMReg` function pair. `parse_vmstorage` is used in the native code instead. (see the code changes in NativeEntryPoint.java & nativeEntryPoint.cpp). Thanks, Jorn ------------- Commit messages: - Remove spurious includes - Remove WeakReferenceCache for now - Rebase fixes - Remove more isTrivial, add WeakReferenceCache to NativeEntryPoint - Remove ciNativeEntryPoint - Remove C2 support for trivial native calls Changes: https://git.openjdk.java.net/panama-foreign/pull/609/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=609&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276647 Stats: 739 lines in 48 files changed: 7 ins; 700 del; 32 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/609.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/609/head:pull/609 PR: https://git.openjdk.java.net/panama-foreign/pull/609 From jbhateja at openjdk.java.net Thu Nov 4 16:44:34 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 4 Nov 2021 16:44:34 GMT Subject: [vectorIntrinsics+compress] RFR: 8276083: Incremental patch to further optimize new compress/expand APIs over X86 [v4] In-Reply-To: References: Message-ID: <1A8UgYrPkWN8JwARP0tzH1SsRs3SUxIsIHQYwmEx1VU=.df9d63be-ea4a-4ed0-8f17-c74941f405d2@github.com> On Tue, 2 Nov 2021 15:43:50 GMT, Paul Sandoz wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8276083: Correcting a typo in CompressExpand template file. > > Yes, we can fix 2/3 separately independently of this branch. In fact i think for 3 we should consider a separate template like with the unit tests. Thanks @PaulSandoz. Integrating this patch. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/157 From jbhateja at openjdk.java.net Thu Nov 4 16:49:20 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 4 Nov 2021 16:49:20 GMT Subject: [vectorIntrinsics] RFR: VectorMask.intoArray intrinsics In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 06:29:59 GMT, Mai ??ng Qu?n Anh wrote: > Hi, > > This small patch applies intrinsics for `VectorMask.intoArray`. This uses the existing `VectorSupport.store` with the signature changes similar to `VectorSupport.load`. > `VectorMask.intoArray` implementation is moved to each concrete class, `VectorMask.toArray` implementation is changed similar to `Vector.toArray`, avoiding referring to `getBits`. > In the hotspot, a small change is made to wrap the node in a `VectorStoreMask` node before passing it to `StoreVectorNode`, similar to how `VectorMask.fromArray` is handled there. > > Thank you very much. PR157, integrated into vectorIntrinsics+compress branch address this. 8276083: Incremental patch to further optimize new compress/expand APIs over X86 #157 ------------- PR: https://git.openjdk.java.net/panama-vector/pull/160 From jbhateja at openjdk.java.net Thu Nov 4 16:44:36 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 4 Nov 2021 16:44:36 GMT Subject: [vectorIntrinsics+compress] Integrated: 8276083: Incremental patch to further optimize new compress/expand APIs over X86 In-Reply-To: References: Message-ID: <2bk4eBOJB857bS-Gj7wh8tLIVn0VIIG2o5-n5G4SZCA=.d5a3981e-c64f-4463-8d9e-fc4ce7f5f3f6@github.com> On Thu, 28 Oct 2021 10:23:31 GMT, Jatin Bhateja wrote: > Summary of changes: > 1) Added both scalar and vector variants of JMH performance tests for Vector.compress/expand and VectorMask.compress APIs. > > 2) Improved performance of operations where mask length is less than 4. Mask loading is a two stage process where in first the boolean array is loaded into a vector and then either transferred to a predicate register or a vector whose size is equivalent to that of underlined SPECIES. A mask whose length is less than 4 will result into a less than 32 bit vector load operation. Operations dependent on smaller masks are now being handled in java side implementation of these and some other APIs. Since the condition for special handling and fallback logic leading to C2 intrinsic call is based on constant expression hence one of the control path is optimized out. This shall also prevent any performance penalty due to failed lazy inline expansion which most often occurs due to unsupported vector sizes. If lazy inline expansion fails then C2 emits a direct call instruction to a callee method and thus we also loose any opportunity for procedure in-lining at that point, a separate [issue ](https://bugs.openjdk.java.net/browse/JDK-8276085)has been created to address this problem. > > 3) Improved performance of VectorMask.compress over legacy non-AVX512 targets, added the missing checks in C2Compiler::is_intrinsics_supported routine to enable procedure in-lining early during parsing if target does not support direct compress/expand instructions. > > 4) Inline expand VectorMask.intoArray operation to trigger boxing-unboxing optimization. This significantly improved the performance of VectorMask.compress in newly added JMH micros. > > Following is the performance data for included JMH micros: > System Configuration: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server 40C 2S) > > A) VectorMask.compress: > > ![image](https://user-images.githubusercontent.com/59989778/139234423-5c340da1-2fb1-4a21-b6d1-bb8b123b0a55.png) > > B) Vector.compress: > > ![image](https://user-images.githubusercontent.com/59989778/139234843-c3846b8d-dff0-4e9e-bf29-6b4dc556cd93.png) > > C) Vector.expand: > > ![image](https://user-images.githubusercontent.com/59989778/139234956-efad1c71-8425-4300-a8c6-c660855f5c58.png) > > Patch has been regressed using tier3 regressions at various AVX levels 0/1/2/3/KNL. > > Kindly review and share your feedback. > > Best Regards, > Jatin This pull request has now been integrated. Changeset: 821635cf Author: Jatin Bhateja URL: https://git.openjdk.java.net/panama-vector/commit/821635cfc31c2839656c0a337a8531fbd00334e3 Stats: 2414 lines in 116 files changed: 2074 ins; 191 del; 149 mod 8276083: Incremental patch to further optimize new compress/expand APIs over X86 Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/panama-vector/pull/157 From duke at openjdk.java.net Thu Nov 4 17:05:29 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Thu, 4 Nov 2021 17:05:29 GMT Subject: [vectorIntrinsics] Withdrawn: VectorMask.intoArray intrinsics In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 06:29:59 GMT, Mai ??ng Qu?n Anh wrote: > Hi, > > This small patch applies intrinsics for `VectorMask.intoArray`. This uses the existing `VectorSupport.store` with the signature changes similar to `VectorSupport.load`. > `VectorMask.intoArray` implementation is moved to each concrete class, `VectorMask.toArray` implementation is changed similar to `Vector.toArray`, avoiding referring to `getBits`. > In the hotspot, a small change is made to wrap the node in a `VectorStoreMask` node before passing it to `StoreVectorNode`, similar to how `VectorMask.fromArray` is handled there. > > Thank you very much. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/160 From duke at openjdk.java.net Thu Nov 4 17:05:29 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Thu, 4 Nov 2021 17:05:29 GMT Subject: [vectorIntrinsics] RFR: VectorMask.intoArray intrinsics In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 06:29:59 GMT, Mai ??ng Qu?n Anh wrote: > Hi, > > This small patch applies intrinsics for `VectorMask.intoArray`. This uses the existing `VectorSupport.store` with the signature changes similar to `VectorSupport.load`. > `VectorMask.intoArray` implementation is moved to each concrete class, `VectorMask.toArray` implementation is changed similar to `Vector.toArray`, avoiding referring to `getBits`. > In the hotspot, a small change is made to wrap the node in a `VectorStoreMask` node before passing it to `StoreVectorNode`, similar to how `VectorMask.fromArray` is handled there. > > Thank you very much. I will close the pull request now. A small point here, do you think `intoArray` should reside in each concrete implementation like other operations to ensure constant information being passed to the compiler. Furthermore, I see that `VectorMask.toArray` is still implemented through `getBits().clone()`, I think we can use `intoArray` for this. Thank you very much. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/160 From sviswanathan at openjdk.java.net Thu Nov 4 22:33:34 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 4 Nov 2021 22:33:34 GMT Subject: [vectorIntrinsics+compress] RFR: 8276083: Incremental patch to further optimize new compress/expand APIs over X86 [v4] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 04:31:10 GMT, Jatin Bhateja wrote: >> Summary of changes: >> 1) Added both scalar and vector variants of JMH performance tests for Vector.compress/expand and VectorMask.compress APIs. >> >> 2) Improved performance of operations where mask length is less than 4. Mask loading is a two stage process where in first the boolean array is loaded into a vector and then either transferred to a predicate register or a vector whose size is equivalent to that of underlined SPECIES. A mask whose length is less than 4 will result into a less than 32 bit vector load operation. Operations dependent on smaller masks are now being handled in java side implementation of these and some other APIs. Since the condition for special handling and fallback logic leading to C2 intrinsic call is based on constant expression hence one of the control path is optimized out. This shall also prevent any performance penalty due to failed lazy inline expansion which most often occurs due to unsupported vector sizes. If lazy inline expansion fails then C2 emits a direct call instruction to a callee method and thus we also loose any opportunity for procedure in-lining at that point, a separate [issu e ](https://bugs.openjdk.java.net/browse/JDK-8276085)has been created to address this problem. >> >> 3) Improved performance of VectorMask.compress over legacy non-AVX512 targets, added the missing checks in C2Compiler::is_intrinsics_supported routine to enable procedure in-lining early during parsing if target does not support direct compress/expand instructions. >> >> 4) Inline expand VectorMask.intoArray operation to trigger boxing-unboxing optimization. This significantly improved the performance of VectorMask.compress in newly added JMH micros. >> >> Following is the performance data for included JMH micros: >> System Configuration: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server 40C 2S) >> >> A) VectorMask.compress: >> >> ![image](https://user-images.githubusercontent.com/59989778/139234423-5c340da1-2fb1-4a21-b6d1-bb8b123b0a55.png) >> >> B) Vector.compress: >> >> ![image](https://user-images.githubusercontent.com/59989778/139234843-c3846b8d-dff0-4e9e-bf29-6b4dc556cd93.png) >> >> C) Vector.expand: >> >> ![image](https://user-images.githubusercontent.com/59989778/139234956-efad1c71-8425-4300-a8c6-c660855f5c58.png) >> >> Patch has been regressed using tier3 regressions at various AVX levels 0/1/2/3/KNL. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8276083: Correcting a typo in CompressExpand template file. src/hotspot/share/opto/c2compiler.cpp line 494: > 492: if (!Matcher::match_rule_supported(Op_CompressM)) return false; > 493: if (!Matcher::match_rule_supported(Op_CompressV)) return false; > 494: break; Instead of break, this should return EnableVectorSupport. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/157 From eliu at openjdk.java.net Fri Nov 5 03:49:26 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Fri, 5 Nov 2021 03:49:26 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v2] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Wed, 3 Nov 2021 07:55:57 GMT, Mai ??ng Qu?n Anh wrote: >> Hi, >> This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. >> Thank you very much. > > Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: > > - fix last true > - further improvement AArch64 needs some changes after this PR, I'm now investigating that. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From ngasson at openjdk.java.net Fri Nov 5 06:52:49 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 5 Nov 2021 06:52:49 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 Message-ID: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> This is a fairly direct port of the X86 code. The changes to frame_aarch64 and foreign_globals_aarch64 are identical: perhaps ForeignGlobals::parse_call_regs_impl() could be moved to shared code? The X86 version has a call to reinit_heapbase() before the return from the stub. I think this is redundant because the heap base register will be clobbered immediately by the native code? I hit a really weird bug in release builds where the first few instructions in the code buffer were overwritten by the fields of OptimizedEntryBlob. I think we need to pass sizeof(OptimizedEntryBlob) instead of sizeof(BufferBlob) as the header_size argument to the RuntimeBlob constructor (none of the other subclasses of BufferBlob have extra fields). I added a header_size argument to BufferBlob's constructor to thread this through. I removed the calls to change the W^X state in on_entry/on_exit calls: in the on_entry case the stub must already be executable because we called into the VM from there, and for on_exit we need the code to be executable not writable otherwise we'll get a SIGBUS as soon as we return to the stub. The newly added stack tests in TestUpcall hit JDK-8275584 on MacOS/AArch64 so I've problem-listed that for now. JMH results from org.openjdk.bench.jdk.incubator.foreign.Upcalls before: Benchmark Mode Cnt Score Error Units Upcalls.jni_args10 avgt 30 450.417 ? 4.755 ns/op Upcalls.jni_args5 avgt 30 245.898 ? 3.171 ns/op Upcalls.jni_blank avgt 30 195.606 ? 5.459 ns/op Upcalls.jni_identity avgt 30 369.788 ? 15.165 ns/op Upcalls.panama_args10 avgt 30 1253.189 ? 62.261 ns/op Upcalls.panama_args5 avgt 30 927.101 ? 35.369 ns/op Upcalls.panama_blank avgt 30 637.708 ? 11.353 ns/op Upcalls.panama_identity avgt 30 697.109 ? 9.971 ns/op After: Benchmark Mode Cnt Score Error Units Upcalls.jni_args10 avgt 30 455.304 ? 21.838 ns/op Upcalls.jni_args5 avgt 30 247.279 ? 2.513 ns/op Upcalls.jni_blank avgt 30 194.113 ? 4.317 ns/op Upcalls.jni_identity avgt 30 366.145 ? 4.912 ns/op Upcalls.panama_args10 avgt 30 236.337 ? 11.072 ns/op Upcalls.panama_args5 avgt 30 223.858 ? 12.345 ns/op Upcalls.panama_blank avgt 30 203.631 ? 8.840 ns/op Upcalls.panama_identity avgt 30 208.783 ? 9.914 ns/op Tested tier1 and jdk_foreign on Linux/AArch64 and MacOS/AArch64. ------------- Commit messages: - 8275646: Implement optimized upcall stubs on AArch64 Changes: https://git.openjdk.java.net/panama-foreign/pull/610/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=610&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275646 Stats: 378 lines in 9 files changed: 344 ins; 4 del; 30 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/610.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/610/head:pull/610 PR: https://git.openjdk.java.net/panama-foreign/pull/610 From aph at openjdk.java.net Fri Nov 5 10:37:27 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 5 Nov 2021 10:37:27 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 In-Reply-To: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> Message-ID: On Fri, 5 Nov 2021 06:47:19 GMT, Nick Gasson wrote: > This is a fairly direct port of the X86 code. The changes to > frame_aarch64 and foreign_globals_aarch64 are identical: perhaps > ForeignGlobals::parse_call_regs_impl() could be moved to shared code? > > The X86 version has a call to reinit_heapbase() before the return from > the stub. I think this is redundant because the heap base register will > be clobbered immediately by the native code? > > I hit a really weird bug in release builds where the first few > instructions in the code buffer were overwritten by the fields of > OptimizedEntryBlob. I think we need to pass sizeof(OptimizedEntryBlob) > instead of sizeof(BufferBlob) as the header_size argument to the > RuntimeBlob constructor (none of the other subclasses of BufferBlob have > extra fields). I added a header_size argument to BufferBlob's > constructor to thread this through. > > I removed the calls to change the W^X state in on_entry/on_exit calls: > in the on_entry case the stub must already be executable because we > called into the VM from there, and for on_exit we need the code to be > executable not writable otherwise we'll get a SIGBUS as soon as we > return to the stub. The newly added stack tests in TestUpcall hit > JDK-8275584 on MacOS/AArch64 so I've problem-listed that for now. > > JMH results from org.openjdk.bench.jdk.incubator.foreign.Upcalls before: > > > Benchmark Mode Cnt Score Error Units > Upcalls.jni_args10 avgt 30 450.417 ? 4.755 ns/op > Upcalls.jni_args5 avgt 30 245.898 ? 3.171 ns/op > Upcalls.jni_blank avgt 30 195.606 ? 5.459 ns/op > Upcalls.jni_identity avgt 30 369.788 ? 15.165 ns/op > Upcalls.panama_args10 avgt 30 1253.189 ? 62.261 ns/op > Upcalls.panama_args5 avgt 30 927.101 ? 35.369 ns/op > Upcalls.panama_blank avgt 30 637.708 ? 11.353 ns/op > Upcalls.panama_identity avgt 30 697.109 ? 9.971 ns/op > > > After: > > > Benchmark Mode Cnt Score Error Units > Upcalls.jni_args10 avgt 30 455.304 ? 21.838 ns/op > Upcalls.jni_args5 avgt 30 247.279 ? 2.513 ns/op > Upcalls.jni_blank avgt 30 194.113 ? 4.317 ns/op > Upcalls.jni_identity avgt 30 366.145 ? 4.912 ns/op > Upcalls.panama_args10 avgt 30 236.337 ? 11.072 ns/op > Upcalls.panama_args5 avgt 30 223.858 ? 12.345 ns/op > Upcalls.panama_blank avgt 30 203.631 ? 8.840 ns/op > Upcalls.panama_identity avgt 30 208.783 ? 9.914 ns/op > > > Tested tier1 and jdk_foreign on Linux/AArch64 and MacOS/AArch64. The AArch64 code parts look reasonable enough, but parts of them seem to repeat some logic already present in MacroAssembler. I guess as it's desirable to stay close to the x86 port that's OK. I'm interested to know where all that 250ns is going. Did you look at -prof perfasm? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/610 From duke at openjdk.java.net Fri Nov 5 11:08:02 2021 From: duke at openjdk.java.net (duke) Date: Fri, 5 Nov 2021 11:08:02 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 97 new changesets Message-ID: Changeset: c0cda1db Author: Ilarion Nakonechnyy Committer: Weijun Wang Date: 2021-10-29 11:37:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0cda1db4fe74b86faa12136336bdf98c96758d2 8273026: Slow LoginContext.login() on multi threading application Reviewed-by: weijun ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java ! test/jdk/javax/security/auth/spi/Loader.java ! test/jdk/javax/security/auth/spi/SecondLoginModule.java Changeset: 4c3491bf Author: Alexander Zuev Date: 2021-10-29 11:44:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c3491bfa5f296b80c56a37cb4fffd6497323ac2 8017175: [TESTBUG] javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java Changeset: 8cc59509 Author: Sean Mullan Date: 2021-10-29 12:42:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8cc59509fe7c01c9032275798ccd1531eb8f2e9f 8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and getExtendedKeyUsage do not throw CertificateParsingException if extension is unparseable Reviewed-by: weijun ! src/java.base/share/classes/sun/security/x509/CertificateExtensions.java + src/java.base/share/classes/sun/security/x509/UnparseableExtension.java ! src/java.base/share/classes/sun/security/x509/X509CertImpl.java + test/jdk/java/security/cert/X509Certificate/GetUnparseableExtensions.java Changeset: a1ec4f96 Author: Alexander Zvegintsev Date: 2021-10-29 13:05:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a1ec4f961841fe0b580c32b37c77e3906ba66966 6854300: [TEST_BUG] java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in jdk6u14 & jdk7 Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java Changeset: d6d82f52 Author: Thomas Stuefe Date: 2021-10-29 13:54:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6d82f52d4a4fac037ee9424503f8b7f11a61c40 8275608: runtime/Metaspace/elastic/TestMetaspaceAllocationMT2 too slow Reviewed-by: mbaesken, shade ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestArena.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestManyArenasManyThreads.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestWithThreads.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocator.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocatorThread.java Changeset: 5facaa24 Author: Brian Burkhalter Date: 2021-10-29 16:12:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5facaa243aef6ad00cf71a047d0325710ce1f0a8 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer Reviewed-by: lancea, iris, alanb ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Changeset: 13265f99 Author: Brian Burkhalter Date: 2021-10-29 16:13:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13265f9901ab8334bbe1e7a571a9c5f386275dbf 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 Reviewed-by: rriggs, naoto ! test/jdk/java/io/File/GetXSpace.java Changeset: cef9db9a Author: Yumin Qi Date: 2021-10-29 16:15:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cef9db9a69061d51630e40b94ceba4b4bf03a0ce 8276039: Remove unnecessary qualifications of java_lang_Class:: Reviewed-by: mikael, iklam ! src/hotspot/share/classfile/javaClasses.cpp Changeset: fe6a2020 Author: Jakob Cornell Committer: Chris Plummer Date: 2021-10-29 17:50:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe6a2020873fe1eb8d4236dc1db3008f485f3195 8271356: Modify jdb to treat an empty command as a repeat of the previous command Reviewed-by: cjplummer, iklam ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003a.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001a.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbCommand.java Changeset: 5021a12c Author: Igor Veresov Date: 2021-10-29 18:03:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5021a12ceada3192e81e2c06b556e7c80cd6cf31 8274855: vectorapi tests failing with assert(!vbox->is_Phi()) failed Reviewed-by: kvn ! src/hotspot/share/opto/vector.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 5bbc8d3c Author: Alex Menkov Date: 2021-10-29 21:38:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5bbc8d3cb2ce487b367ee1a621d78699c9b30100 8274621: NullPointerException because listenAddress[0] is null Reviewed-by: sspitsyn, lmesnik, cjplummer ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: 68756782 Author: Sergey Bylokhov Date: 2021-10-30 09:03:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/687567822a5380fb7d8c5b54ae548b2a5c848187 8273831: PrintServiceLookup spawns 2 threads in the current classloader, getting orphaned Reviewed-by: aivanov ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java + test/jdk/javax/print/PrintServiceLookup/FlushCustomClassLoader.java Changeset: b7104ba9 Author: Alexander Zuev Date: 2021-10-30 10:01:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7104ba9a9006ab65e08ea9d7db22e72611ed07c 8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: bf2e9ee9 Author: Man Cao Date: 2021-10-31 04:58:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf2e9ee9d321ed289466b2410f12ad10504d01a2 8275080: G1CollectedHeap::expand() returns the wrong value Co-authored-by: Jonathan Joo Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 158831e4 Author: Thomas Stuefe Date: 2021-11-01 05:13:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/158831e4c3fa637905fda6f28e9adf8e957b9e55 8274320: os::fork_and_exec() should be using posix_spawn Reviewed-by: mdoerr, dholmes ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/vmError.cpp Changeset: 5bb1992b Author: Christian Hagedorn Date: 2021-11-01 08:22:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5bb1992b8408a0d196b1afa308bc00d007458dbd 8275868: ciReplay: Inlining fails with "unloaded signature classes" due to wrong protection domains Reviewed-by: kvn, dlong, thartmann ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciReplay.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/DumpReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java Changeset: dbf5100d Author: Zhengyu Gu Date: 2021-11-01 12:17:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dbf5100dd705fbe4a3aeae49405ca541d581f106 8276201: Shenandoah: Race results degenerated GC to enter wrong entry point Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp Changeset: 89ade1d7 Author: Aleksey Shipilev Date: 2021-11-01 12:30:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/89ade1d7e88ee005c3fd2136d84e298d94f9a67c 8273416: C2: assert(false) failed: bad AD file after JDK-8252372 with UseSSE={0,1} Reviewed-by: kvn, roland ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/share/opto/castnode.hpp Changeset: 4ac8403f Author: Erik Gahlin Date: 2021-11-01 12:33:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ac8403f9a4cedcb5d56bcd34a6bbfa51d67ca18 8276218: JFR: Clean up jdk.jfr.dcmd Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java Changeset: f55e68c9 Author: Patricio Chilano Mateo Date: 2021-11-01 15:27:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f55e68c92924bb70471a4851f616d4c3065ffa92 8275950: Use only _thread_in_vm in ~ThreadBlockInVMPreprocess() Reviewed-by: dholmes, dcubed ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepoint.hpp Changeset: c8abe354 Author: Leo Korinth Date: 2021-11-01 15:37:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c8abe354c1ddc988ff54b9a96a4a825e2aa70f4b 8276121: G1: Remove unused and uninitialized _g1h in g1SATBMarkQueueSet.hpp Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1SATBMarkQueueSet.hpp Changeset: e265f838 Author: Thomas Schatzl Date: 2021-11-01 16:48:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e265f83858b84451258677f130f98be5375a417a 8276107: Preventive collections trigger before maxing out heap Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1Policy.cpp Changeset: 97715440 Author: Patrick Concannon Date: 2021-11-01 17:11:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/977154400be786c500f36ba14188bff79db57075 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations Reviewed-by: alanb, dfuchs, vtewari ! src/java.base/share/classes/java/net/DatagramSocketImpl.java ! src/java.base/share/classes/java/net/NetMulticastSocket.java + test/jdk/java/net/DatagramSocket/OldDatagramSocketImplTest.java Changeset: 99b7b95e Author: Zhengyu Gu Date: 2021-11-01 19:38:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99b7b95e014da6e491ba7adfd21de53d6ae166fe 8276205: Shenandoah: CodeCache_lock should always be held for initializing code cache iteration Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Changeset: 47e7a425 Author: Alisen Chung Committer: Alexander Zuev Date: 2021-11-01 22:29:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47e7a42594f1c36f71cdf4d383080bf8d616b7e7 8262945: [macos] Regression Manual Test for Key Events Fails Reviewed-by: prr, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m Changeset: 2eafa036 Author: Pavel Rappo Date: 2021-11-01 22:50:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2eafa036c03d3e8f3dba8f67dd37b484874dc3d3 8276234: Trivially clean up locale-related code Reviewed-by: redestad, naoto, iris ! src/java.base/share/classes/java/time/chrono/JapaneseChronology.java ! src/java.base/share/classes/sun/util/locale/BaseLocale.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java Changeset: acceffcb Author: Phil Race Date: 2021-11-02 02:49:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/acceffcbf73aa4416c487f890f3ca65e55e47164 8273704: DrawStringWithInfiniteXform.java failed : drawString with InfiniteXform transform takes long time Reviewed-by: serb, psadhukhan ! test/jdk/java/awt/FontClass/DrawStringWithInfiniteXform.java Changeset: 0488ebdf Author: Aleksey Shipilev Date: 2021-11-02 06:38:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0488ebdf14dacfa79d98de16ed949c813dd88701 8276105: C2: Conv(D|F)2(I|L)Nodes::Ideal should handle rounding correctly Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/convertnode.cpp Changeset: 9bf31652 Author: Masanori Yano Committer: Alan Bateman Date: 2021-11-02 06:44:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9bf31652cbe8eb2699babe5e52e62ea1f1578588 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc Reviewed-by: alanb ! src/java.base/share/classes/java/io/DataOutput.java ! src/java.base/share/classes/java/io/RandomAccessFile.java Changeset: 92be9d8c Author: Ludvig Janiuk Committer: Sean Coffey Date: 2021-11-02 09:46:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92be9d8c535274eea4edd06273e6d7811f6bb113 8276236: Table headers missing in Formatter api docs Reviewed-by: coffeys, iris ! src/java.base/share/classes/java/util/Formatter.java Changeset: b7a06be9 Author: Aleksey Shipilev Date: 2021-11-02 10:26:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7a06be98d3057dac4adbb7f4071ac62cf88fe52 8252990: Intrinsify Unsafe.storeStoreFence Reviewed-by: dholmes, thartmann, whuang ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 9971a2ca Author: Severin Gehwolf Date: 2021-11-02 10:39:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9971a2cab3892a17f3fd39243df5ecfff5b9f108 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) Reviewed-by: hseigel, mchung ! src/java.base/linux/classes/jdk/internal/platform/CgroupV1Metrics.java ! src/java.base/linux/classes/jdk/internal/platform/CgroupV1MetricsImpl.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java ! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java ! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java Changeset: 8630f55e Author: Hannes Walln?fer Date: 2021-11-02 12:10:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8630f55ed7a0483ec5dcb13a7f53b52bc4ab6fc6 8275406: Add copy-to-clipboard feature to snippet UI Reviewed-by: erikj, jjg ! make/CompileInterimLangtools.gmk ! make/modules/jdk.javadoc/Java.gmk ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/copy.svg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: 5b4e3986 Author: Yoshiki Sato Committer: Sean Coffey Date: 2021-11-02 13:02:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b4e39863dbc0d61e91675261dd6887f704ab868 8275766: (tz) Update Timezone Data to 2021e 8275849: TestZoneInfo310.java fails with tzdata2021e Reviewed-by: naoto, iris, erikj, coffeys ! make/data/tzdata/VERSION ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/northamerica ! src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java Changeset: b889f2a8 Author: Thomas Stuefe Date: 2021-11-02 13:04:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b889f2a88a5e182d2424b741d8fedf2c784442f1 8276175: codestrings.validate_vm gtest still broken on ppc64 after JDK-8276046 Reviewed-by: mdoerr ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: cd778f5b Author: Alexander Zuev Date: 2021-11-02 13:23:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd778f5b049d52b68ab5872aad5f81e86e1718f7 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on Windows Reviewed-by: prr ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Debug/DumpOnKey/DumpOnKey.java Changeset: 495c828a Author: Naoto Sato Date: 2021-11-02 16:08:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/495c828ae95205885b091dde795b517ba332a2b1 8276188: Clarify "default charset" descriptions in String class Reviewed-by: iris, joehw ! src/java.base/share/classes/java/lang/String.java Changeset: fa4ce824 Author: Brian Burkhalter Date: 2021-11-02 16:27:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa4ce824a39264e765b8236ee58b1f28faa371e0 8276260: (se) Remove java/nio/channels/Selector/Wakeup.java from ProblemList (win) Reviewed-by: alanb ! test/jdk/ProblemList.txt Changeset: 8fc16f16 Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-02 16:32:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8fc16f1605b396bfb9265a97bc126d435d6d5951 8275729: Qualified method names in CodeHeap Analytics Reviewed-by: yyang, thartmann ! src/hotspot/share/code/codeHeapState.cpp + test/hotspot/jtreg/serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java Changeset: 01105d69 Author: Daniel D. Daugherty Date: 2021-11-02 16:50:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01105d6985b39d4064b9066eab3612da5a401685 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java Reviewed-by: bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: 6a04899b Author: Markus Karg Committer: Lance Andersen Date: 2021-11-02 18:06:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6a04899ba1a62f52f7e28cc2ed72bdca115e6562 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB Reviewed-by: lancea ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: bb92fb02 Author: Alex Menkov Date: 2021-11-02 21:57:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb92fb02ca8c5795989065a9037748dc39ed77db 8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string Reviewed-by: sspitsyn, lmesnik ! test/jdk/sun/tools/jps/JpsHelper.java Changeset: 2b02b6f5 Author: Guoxiong Li Date: 2021-11-03 01:57:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b02b6f513b062261195ca1edd059d16abb7bec6 8274942: AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java + test/langtools/tools/javac/annotations/typeAnnotations/NestTypeAnnotation.java Changeset: 87b926eb Author: sunguoyun Committer: Igor Veresov Date: 2021-11-03 05:51:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87b926ebb7f1e341da858f7a9892377586abc026 8275086: compiler/c2/irTests/TestPostParseCallDevirtualization.java fails when compiler1 is disabled Reviewed-by: iveresov ! test/hotspot/jtreg/compiler/c2/irTests/TestPostParseCallDevirtualization.java Changeset: 7439b59b Author: Christian Hagedorn Date: 2021-11-03 08:44:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7439b59b5a6816269b16d210ef10779fc9def8e2 8276044: ciReplay: C1 does not dump a replay file when using DumpReplay as compile command option Reviewed-by: kvn, thartmann, dlong ! src/hotspot/share/c1/c1_Compilation.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/TestDumpReplayCommandLine.java Changeset: 465d350d Author: Aleksey Shipilev Date: 2021-11-03 09:06:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/465d350d0b3cac277a58b9f8ece196c1cde68e80 8276157: C2: Compiler stack overflow during escape analysis on Linux x86_32 Reviewed-by: kvn, thartmann ! src/hotspot/os_cpu/linux_x86/globals_linux_x86.hpp Changeset: 61506336 Author: Pavel Rappo Date: 2021-11-03 10:07:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/615063364ab6bdd3fa83401745e05b45e13eacdb 8276348: Use blessed modifier order in java.base Reviewed-by: dfuchs, darcy, iris, rriggs, martin ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/lang/Process.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/WeakPairMap.java ! src/java.base/share/classes/java/lang/invoke/AbstractConstantGroup.java ! src/java.base/share/classes/java/lang/invoke/CallSite.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/util/ImmutableCollections.java ! src/java.base/share/classes/jdk/internal/icu/util/CodePointTrie.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java ! src/java.base/share/classes/jdk/internal/logger/SimpleConsoleLogger.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLHandshake.java Changeset: a316c06e Author: Zhengyu Gu Date: 2021-11-03 12:08:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a316c06e03e06b86ceca376cf20dcb9c526905f5 8275730: Relax memory constraint on MultiThreadedRefCounter Reviewed-by: mgronlun, minqi ! src/hotspot/share/jfr/utilities/jfrRefCountPointer.hpp Changeset: be1ca2bd Author: Hamlin Li Date: 2021-11-03 12:39:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/be1ca2bd201170b0d280030a2aae4c8d1da9f4af 8276298: G1: Remove unused G1SegmentedArrayBufferList::add Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp Changeset: 87318460 Author: Daniel D. Daugherty Date: 2021-11-03 15:02:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87318460012d3fa1a8d3e8749d7a20328b27b826 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 Reviewed-by: alanb ! test/jdk/ProblemList.txt Changeset: 61cb4bc6 Author: Tobias Holenstein Committer: Christian Hagedorn Date: 2021-11-03 15:31:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b 8276036: The value of full_count in the message of insufficient codecache is wrong Reviewed-by: kvn, dlong, thartmann, chagedorn ! src/hotspot/share/code/codeCache.cpp Changeset: 724bf3be Author: Aleksey Shipilev Date: 2021-11-03 15:41:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/724bf3be1458f7da502f8772be6151bed826b4f7 8275604: Zero: Reformat opclabels_data Reviewed-by: adinn, zgu ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 0ef8cbe3 Author: Phil Race Date: 2021-11-03 16:22:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ef8cbe32540814d4c0be9c7b0f78486408657a7 8276385: Re-run blessed-modifier-order script on java.desktop and jdk.accessibility Reviewed-by: serb ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifInteroperabilityTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifParentTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/FaxTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/GeoTIFFTagSet.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListColor.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityListenerList.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventID.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventQueueMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java Changeset: 7115892f Author: Daniel Fuchs Date: 2021-11-03 16:23:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7115892f96a5a57ce9d37602038b787d19da5d81 8276401: Use blessed modifier order in java.net.http Reviewed-by: prappo, rriggs ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/DebugLogger.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/FlowTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/MinimalFuture.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SequentialScheduler.java Changeset: 684edbb4 Author: Brian Burkhalter Date: 2021-11-03 16:55:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/684edbb4c884cbc3e05118e4bc9808b5d5b71a74 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) Reviewed-by: alanb ! src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java Changeset: c7f070f5 Author: Jakob Cornell Committer: Chris Plummer Date: 2021-11-03 18:18:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7f070f5f17dad661cc3296f2e3cd7a1cd5fc742 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" Reviewed-by: cjplummer, iklam ! test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java Changeset: 32895ac6 Author: Ivan ?ipka Committer: Mark Sheppard Date: 2021-11-03 19:30:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 Reviewed-by: bpb, msheppar + out ! test/jdk/ProblemList.txt Changeset: f3320d2f Author: Joe Darcy Date: 2021-11-03 21:20:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f3320d2fbd28349fa5eab3ea0da0ff0a3ef54c62 8276588: Change "ccc" to "CSR" in HotSpot sources Reviewed-by: dcubed, kbarrett ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 0ab910d6 Author: Jie Fu Date: 2021-11-03 22:45:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ab910d626a05106e1366438aeb5b16e16374c2f 8276066: Reset LoopPercentProfileLimit for x86 due to suboptimal performance Reviewed-by: thartmann, kvn ! src/hotspot/cpu/x86/c2_globals_x86.hpp + test/micro/org/openjdk/bench/vm/compiler/LoopUnroll.java Changeset: ce8c7670 Author: Claes Redestad Date: 2021-11-03 22:57:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce8c76700ba854f43c48d32b068b30e7d78d9d1e 8276220: Reduce excessive allocations in DateTimeFormatter Reviewed-by: scolebourne, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/java/time/format/DateTimePrintContext.java ! test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java + test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java Changeset: 603bba28 Author: Yumin Qi Date: 2021-11-03 23:16:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/603bba282a089928fd23f8da23a7c1b2d52944ef 8271420: Extend CDS custom loader support to Windows platform Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/classListParser.cpp ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/CustomAppLoader.java ! test/lib/jdk/test/lib/Platform.java Changeset: 558ee40a Author: Yasumasa Suenaga Date: 2021-11-04 04:34:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/558ee40a4ac158e5be8269c87b7e18af77dd14c5 8276615: Update CR number of some tests in ProblemList-zgc.txt Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: fb0be81f Author: Aleksey Shipilev Date: 2021-11-04 08:03:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb0be81f0148d9aea73321a0c2bd83b2e477d952 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence Reviewed-by: psandoz, aph, dholmes ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 9eadcbb4 Author: Aleksey Shipilev Date: 2021-11-04 08:08:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9eadcbb47e902f42d933ba68e24f2bfb0ee20915 8276217: Harmonize StrictMath intrinsics handling Reviewed-by: aph, kvn ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp Changeset: a1f4c428 Author: Christian Hagedorn Date: 2021-11-04 08:53:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a1f4c428ba1b78a4e18afb87c94a5c731a5aa706 8276227: ciReplay: SIGSEGV if classfile for replay compilation is not present after JDK-8275868 Reviewed-by: kvn, thartmann, dlong ! src/hotspot/share/ci/ciReplay.cpp + test/hotspot/jtreg/compiler/ciReplay/TestNoClassFile.java Changeset: c62b3476 Author: Aleksey Shipilev Date: 2021-11-04 09:03:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c62b3476ce12cea633abead0d6376ea0a05f92f9 8276623: JDK-8275650 accidentally pushed "out" file Reviewed-by: tschatzl, dholmes - out Changeset: 3613ce7c Author: Aleksey Shipilev Date: 2021-11-04 10:23:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3613ce7c7d5bc8b7d603e1cf6a123588339aed3f 8275586: Zero: Simplify interpreter initialization Reviewed-by: aph, adinn ! src/hotspot/cpu/zero/vm_version_zero.cpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: ee499632 Author: Julia Boes Date: 2021-11-04 11:31:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ee499632586eabb3dab209645d5b9c781a09034b 8275534: com.sun.net.httpserver.BasicAuthenticator should check whether "realm" is a quoted string Reviewed-by: michaelm, dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java + src/jdk.httpserver/share/classes/sun/net/httpserver/Utils.java + test/jdk/com/sun/net/httpserver/BasicAuthenticatorRealm.java ! test/jdk/com/sun/net/httpserver/bugs/BasicAuthenticatorExceptionCheck.java Changeset: 7de653e4 Author: Hamlin Li Date: 2021-11-04 12:31:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7de653e428ee38339ec38533659b23a52e275f3f 8276301: G1: Refine implementation of G1CardSetFreePool::memory_sizes() Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp Changeset: 19075b3f Author: Hannes Walln?fer Date: 2021-11-04 13:06:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/19075b3f6b21f6d3b0624ef8e835b3cfc53228de 8275788: Create code element with suitable attributes for code snippets Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: a6fa6ed1 Author: Per Liden Date: 2021-11-04 13:47:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6fa6ed1edc6f473a7fea1fa00edd467ab778983 8268779: ZGC: runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with "OutOfMemoryError: Java heap space" Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/zDriver.cpp Changeset: 5acff753 Author: Evgeny Astigeevich Committer: Vladimir Kozlov Date: 2021-11-04 15:01:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5acff75379a4ad0acfcfc6a64fcc4b588ef048c7 8276429: CodeHeapState::print_names() fails with "assert(klass->is_loader_alive()) failed: must be alive" Reviewed-by: kvn ! src/hotspot/share/code/codeHeapState.cpp Changeset: 49b7b2ea Author: Magnus Ihse Bursie Date: 2021-11-04 15:06:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/49b7b2ea0971fe99567bdbd962d63b90ff2eeefd 8276640: Use blessed modifier order in jfr code Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/FilePurger.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PrivateAccess.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java Changeset: afb502e2 Author: Aleksey Shipilev Date: 2021-11-04 15:41:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/afb502e28a81183cef76a7e60fc052e8cad3afe3 8276550: Use SHA256 hash in build.tools.depend.Depend Reviewed-by: adinn, aph, andrew, ihse ! make/jdk/src/classes/build/tools/depend/Depend.java Changeset: bf4ddf9c Author: Pavel Rappo Date: 2021-11-04 15:51:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf4ddf9cb7408db321e7fd73600a5a9a85ca49eb 8276338: Minor improve of wording for String.to(Lower|Upper)Case Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/lang/String.java Changeset: b57715a1 Author: Pavel Rappo Date: 2021-11-04 15:56:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b57715a117d9b7f79fcf4fec3b8f369b6aa42598 8276573: Use blessed modifier order in jdk.javadoc Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java Changeset: 7bb21733 Author: Brian Burkhalter Date: 2021-11-04 16:33:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7bb2173383bc1c0d55564d31303a547957d87a15 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly Reviewed-by: alanb ! test/jdk/ProblemList.txt ! test/jdk/java/nio/channels/FileChannel/LargeGatheringWrite.java Changeset: 1533b819 Author: Magnus Ihse Bursie Date: 2021-11-04 17:02:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1533b8191bed9d65ab4af03945584d8b2276d828 8276629: Use blessed modifier order in core-libs code Reviewed-by: dholmes, aefimov, dfuchs, mchung, iris ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/java.rmi/share/classes/java/rmi/server/LoaderHandler.java ! src/java.rmi/share/classes/java/rmi/server/RMISocketFactory.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObject.java ! src/java.rmi/share/classes/java/rmi/server/RemoteRef.java ! src/java.rmi/share/classes/java/rmi/server/RemoteStub.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java ! src/java.rmi/share/classes/sun/rmi/transport/ObjectTable.java ! src/java.rmi/share/classes/sun/rmi/transport/Target.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/jdk.dynalink/share/classes/jdk/dynalink/BiClassValue.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Annotation.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Dependencies.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ResourceFilter.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContext.java ! src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContextFactory.java Changeset: 99d4b07c Author: Ludvig Janiuk Committer: Mandy Chung Date: 2021-11-04 17:26:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99d4b07cddec05428e4d578ba6f494f51b92e841 8276649: MethodHandles.Lookup docs: replace the table in the cross-module access check section with list Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 2b5a32c7 Author: Zhengyu Gu Date: 2021-11-04 19:40:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b5a32c73f22c69d7ccedac761af1dbb4a7f297d 8275718: Relax memory constraint on exception counter updates Reviewed-by: dholmes, minqi ! src/hotspot/share/utilities/exceptions.cpp Changeset: 81203efe Author: Magnus Ihse Bursie Date: 2021-11-04 19:44:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81203efe411320ff4e390605f980d14e7f70252f 8276655: Use blessed modifier order in SCTP Reviewed-by: alanb, dfuchs ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/AssociationChange.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/PeerAddrChange.java Changeset: dcf36f87 Author: Dean Long Date: 2021-11-04 19:52:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dcf36f87f87d52490c1f0434c2fca99fc8fd90a2 8275670: ciReplay: java.lang.NoClassDefFoundError when trying to load java/lang/invoke/LambdaForm$MH Reviewed-by: kvn, chagedorn ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp + test/hotspot/jtreg/compiler/ciReplay/TestLambdas.java Changeset: 7e87f946 Author: Ludvig Janiuk Committer: Mandy Chung Date: 2021-11-04 20:46:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e87f946cedf93f19c38fd596039a16394c03ea4 8276652: Missing row headers in MethodHandles.Lookup docs Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 8ec80c4b Author: Ludvig Janiuk Committer: Naoto Sato Date: 2021-11-04 21:06:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8ec80c4bc1c3169963137b5a16a1b787540a3589 8276653: Missing row headers in j.l.Character docs Reviewed-by: naoto ! src/java.base/share/classes/java/lang/Character.java Changeset: 7b1916ef Author: Alisen Chung Committer: Phil Race Date: 2021-11-04 21:53:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b1916efda95a46439cf42e006593361d12a8823 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on macOs Reviewed-by: prr ! test/jdk/ProblemList.txt Changeset: e21b5c7b Author: Mandy Chung Date: 2021-11-04 23:51:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e21b5c7b3781430ecf568e7f5c89ef3391e06d9e 8276650: GenGraphs does not produce deterministic output Reviewed-by: iris ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java ! test/langtools/tools/jdeps/modules/DotFileTest.java Changeset: 9ad4d3d0 Author: Sandhya Viswanathan Date: 2021-11-05 03:30:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ad4d3d06bb356436d69af07726ef6727c500f59 8276025: Hotspot's libsvml.so may conflict with user dependency Reviewed-by: kvn, erikj, psandoz, ihse ! make/modules/jdk.incubator.vector/Lib.gmk ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp = src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_acos_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_asin_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cbrt_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_expm1_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log10_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log1p_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sinh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tanh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_acos_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_asin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cbrt_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cos_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_expm1_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log10_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log1p_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_pow_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sinh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tan_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tanh_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_acos_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_asin_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan2_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_cbrt_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_cosh_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_exp_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_expm1_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_log10_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_atan_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_cbrt_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_exp_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_expm1_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log10_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log1p_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log_linux_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cbrt_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_expm1_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_pow_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sinh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tanh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cbrt_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_expm1_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_pow_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sinh_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tanh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_acos_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_asin_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan2_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_cbrt_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_cosh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_exp_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_expm1_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_hypot_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log10_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log1p_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_pow_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_sinh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_tan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_tanh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_acos_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_asin_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan2_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_cbrt_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_cosh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_exp_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_expm1_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log10_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log1p_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_sinh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_tanh_windows_x86.S ! test/jdk/jdk/incubator/vector/ImageTest.java = test/jdk/jdk/incubator/vector/LoadJsvmlTest.java Changeset: 396132ff Author: Jaikiran Pai Date: 2021-11-05 03:44:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/396132ff1e56463ad195cac5c9ac8e2eac5a16e8 8275509: ModuleDescriptor.hashCode isn't reproducible across builds Reviewed-by: alanb, ihse ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java + test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java Changeset: 8e17ce00 Author: Ioi Lam Date: 2021-11-05 04:37:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8e17ce00316a765bbedefc34dc5898ba4f3f2144 8275185: Remove dead code and clean up jvmstat LocalVmManager Reviewed-by: cjplummer, redestad, kevinw ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java Changeset: 7281861e Author: Thomas Stuefe Date: 2021-11-05 05:15:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7281861e0662e6c51507066a1f12673a236c7491 8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 Reviewed-by: mchung, coleenp, dholmes ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp - src/hotspot/share/oops/reflectionAccessorImplKlassHelper.cpp - src/hotspot/share/oops/reflectionAccessorImplKlassHelper.hpp ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java - test/hotspot/jtreg/serviceability/dcmd/vm/ShowReflectionTargetTest.java Changeset: 96c396b7 Author: Ningsheng Jian Date: 2021-11-05 07:45:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96c396b701e290fc3e1124b1c862b41e02e9c1d9 8276151: AArch64: Incorrect result for double to int vector conversion Reviewed-by: aph, psandoz ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! test/hotspot/jtreg/compiler/vectorapi/VectorCastShape128Test.java ! test/hotspot/jtreg/compiler/vectorapi/VectorCastShape64Test.java Changeset: 323d2017 Author: Leo Korinth Date: 2021-11-05 09:25:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/323d2017959dc96d25eaa1aad6404586099c237e 8275506: Rename allocated_on_stack to allocated_on_stack_or_embedded Reviewed-by: stuefe ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/utilities/growableArray.cpp ! test/hotspot/gtest/utilities/test_growableArray.cpp Changeset: 3c0faa73 Author: Leo Korinth Date: 2021-11-05 09:42:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3c0faa73522bd004b66cb9e477f43e15a29842e6 8276173: Clean up and remove unneeded casts in HeapDumper Reviewed-by: coleenp, hseigel ! src/hotspot/share/services/heapDumper.cpp Changeset: d95299a4 Author: Patrick Concannon Date: 2021-11-05 10:39:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d95299a4d751449816ad2a88359f1e48e9608246 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java Reviewed-by: dfuchs, alanb, vtewari ! test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java ! test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java Changeset: a4e8d061 Author: duke Date: 2021-11-05 11:00:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a4e8d061d80cf9be501c9c700450891a445e7767 Automatic merge of jdk:master into master Changeset: 330a9f8c Author: duke Date: 2021-11-05 11:01:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/330a9f8c53b62e5f11775b2842709c77835a4971 Automatic merge of master into foreign-memaccess+abi ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 0268d48b Author: duke Date: 2021-11-05 11:01:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0268d48b13698a12af66d7b42f6bbd260f8c03af Automatic merge of foreign-memaccess+abi into foreign-jextract From duke at openjdk.java.net Fri Nov 5 11:13:48 2021 From: duke at openjdk.java.net (duke) Date: Fri, 5 Nov 2021 11:13:48 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 96 new changesets Message-ID: Changeset: c0cda1db Author: Ilarion Nakonechnyy Committer: Weijun Wang Date: 2021-10-29 11:37:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0cda1db4fe74b86faa12136336bdf98c96758d2 8273026: Slow LoginContext.login() on multi threading application Reviewed-by: weijun ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java ! test/jdk/javax/security/auth/spi/Loader.java ! test/jdk/javax/security/auth/spi/SecondLoginModule.java Changeset: 4c3491bf Author: Alexander Zuev Date: 2021-10-29 11:44:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c3491bfa5f296b80c56a37cb4fffd6497323ac2 8017175: [TESTBUG] javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java Changeset: 8cc59509 Author: Sean Mullan Date: 2021-10-29 12:42:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8cc59509fe7c01c9032275798ccd1531eb8f2e9f 8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and getExtendedKeyUsage do not throw CertificateParsingException if extension is unparseable Reviewed-by: weijun ! src/java.base/share/classes/sun/security/x509/CertificateExtensions.java + src/java.base/share/classes/sun/security/x509/UnparseableExtension.java ! src/java.base/share/classes/sun/security/x509/X509CertImpl.java + test/jdk/java/security/cert/X509Certificate/GetUnparseableExtensions.java Changeset: a1ec4f96 Author: Alexander Zvegintsev Date: 2021-10-29 13:05:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a1ec4f961841fe0b580c32b37c77e3906ba66966 6854300: [TEST_BUG] java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in jdk6u14 & jdk7 Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java Changeset: d6d82f52 Author: Thomas Stuefe Date: 2021-10-29 13:54:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6d82f52d4a4fac037ee9424503f8b7f11a61c40 8275608: runtime/Metaspace/elastic/TestMetaspaceAllocationMT2 too slow Reviewed-by: mbaesken, shade ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestArena.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestManyArenasManyThreads.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestWithThreads.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocator.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocatorThread.java Changeset: 5facaa24 Author: Brian Burkhalter Date: 2021-10-29 16:12:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5facaa243aef6ad00cf71a047d0325710ce1f0a8 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer Reviewed-by: lancea, iris, alanb ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Changeset: 13265f99 Author: Brian Burkhalter Date: 2021-10-29 16:13:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13265f9901ab8334bbe1e7a571a9c5f386275dbf 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 Reviewed-by: rriggs, naoto ! test/jdk/java/io/File/GetXSpace.java Changeset: cef9db9a Author: Yumin Qi Date: 2021-10-29 16:15:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cef9db9a69061d51630e40b94ceba4b4bf03a0ce 8276039: Remove unnecessary qualifications of java_lang_Class:: Reviewed-by: mikael, iklam ! src/hotspot/share/classfile/javaClasses.cpp Changeset: fe6a2020 Author: Jakob Cornell Committer: Chris Plummer Date: 2021-10-29 17:50:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe6a2020873fe1eb8d4236dc1db3008f485f3195 8271356: Modify jdb to treat an empty command as a repeat of the previous command Reviewed-by: cjplummer, iklam ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003a.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001a.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbCommand.java Changeset: 5021a12c Author: Igor Veresov Date: 2021-10-29 18:03:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5021a12ceada3192e81e2c06b556e7c80cd6cf31 8274855: vectorapi tests failing with assert(!vbox->is_Phi()) failed Reviewed-by: kvn ! src/hotspot/share/opto/vector.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 5bbc8d3c Author: Alex Menkov Date: 2021-10-29 21:38:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5bbc8d3cb2ce487b367ee1a621d78699c9b30100 8274621: NullPointerException because listenAddress[0] is null Reviewed-by: sspitsyn, lmesnik, cjplummer ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: 68756782 Author: Sergey Bylokhov Date: 2021-10-30 09:03:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/687567822a5380fb7d8c5b54ae548b2a5c848187 8273831: PrintServiceLookup spawns 2 threads in the current classloader, getting orphaned Reviewed-by: aivanov ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java + test/jdk/javax/print/PrintServiceLookup/FlushCustomClassLoader.java Changeset: b7104ba9 Author: Alexander Zuev Date: 2021-10-30 10:01:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7104ba9a9006ab65e08ea9d7db22e72611ed07c 8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: bf2e9ee9 Author: Man Cao Date: 2021-10-31 04:58:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf2e9ee9d321ed289466b2410f12ad10504d01a2 8275080: G1CollectedHeap::expand() returns the wrong value Co-authored-by: Jonathan Joo Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 158831e4 Author: Thomas Stuefe Date: 2021-11-01 05:13:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/158831e4c3fa637905fda6f28e9adf8e957b9e55 8274320: os::fork_and_exec() should be using posix_spawn Reviewed-by: mdoerr, dholmes ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/vmError.cpp Changeset: 5bb1992b Author: Christian Hagedorn Date: 2021-11-01 08:22:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5bb1992b8408a0d196b1afa308bc00d007458dbd 8275868: ciReplay: Inlining fails with "unloaded signature classes" due to wrong protection domains Reviewed-by: kvn, dlong, thartmann ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciReplay.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/DumpReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java Changeset: dbf5100d Author: Zhengyu Gu Date: 2021-11-01 12:17:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dbf5100dd705fbe4a3aeae49405ca541d581f106 8276201: Shenandoah: Race results degenerated GC to enter wrong entry point Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp Changeset: 89ade1d7 Author: Aleksey Shipilev Date: 2021-11-01 12:30:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/89ade1d7e88ee005c3fd2136d84e298d94f9a67c 8273416: C2: assert(false) failed: bad AD file after JDK-8252372 with UseSSE={0,1} Reviewed-by: kvn, roland ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/share/opto/castnode.hpp Changeset: 4ac8403f Author: Erik Gahlin Date: 2021-11-01 12:33:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ac8403f9a4cedcb5d56bcd34a6bbfa51d67ca18 8276218: JFR: Clean up jdk.jfr.dcmd Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java Changeset: f55e68c9 Author: Patricio Chilano Mateo Date: 2021-11-01 15:27:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f55e68c92924bb70471a4851f616d4c3065ffa92 8275950: Use only _thread_in_vm in ~ThreadBlockInVMPreprocess() Reviewed-by: dholmes, dcubed ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepoint.hpp Changeset: c8abe354 Author: Leo Korinth Date: 2021-11-01 15:37:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c8abe354c1ddc988ff54b9a96a4a825e2aa70f4b 8276121: G1: Remove unused and uninitialized _g1h in g1SATBMarkQueueSet.hpp Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1SATBMarkQueueSet.hpp Changeset: e265f838 Author: Thomas Schatzl Date: 2021-11-01 16:48:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e265f83858b84451258677f130f98be5375a417a 8276107: Preventive collections trigger before maxing out heap Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1Policy.cpp Changeset: 97715440 Author: Patrick Concannon Date: 2021-11-01 17:11:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/977154400be786c500f36ba14188bff79db57075 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations Reviewed-by: alanb, dfuchs, vtewari ! src/java.base/share/classes/java/net/DatagramSocketImpl.java ! src/java.base/share/classes/java/net/NetMulticastSocket.java + test/jdk/java/net/DatagramSocket/OldDatagramSocketImplTest.java Changeset: 99b7b95e Author: Zhengyu Gu Date: 2021-11-01 19:38:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99b7b95e014da6e491ba7adfd21de53d6ae166fe 8276205: Shenandoah: CodeCache_lock should always be held for initializing code cache iteration Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Changeset: 47e7a425 Author: Alisen Chung Committer: Alexander Zuev Date: 2021-11-01 22:29:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47e7a42594f1c36f71cdf4d383080bf8d616b7e7 8262945: [macos] Regression Manual Test for Key Events Fails Reviewed-by: prr, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m Changeset: 2eafa036 Author: Pavel Rappo Date: 2021-11-01 22:50:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2eafa036c03d3e8f3dba8f67dd37b484874dc3d3 8276234: Trivially clean up locale-related code Reviewed-by: redestad, naoto, iris ! src/java.base/share/classes/java/time/chrono/JapaneseChronology.java ! src/java.base/share/classes/sun/util/locale/BaseLocale.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java Changeset: acceffcb Author: Phil Race Date: 2021-11-02 02:49:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/acceffcbf73aa4416c487f890f3ca65e55e47164 8273704: DrawStringWithInfiniteXform.java failed : drawString with InfiniteXform transform takes long time Reviewed-by: serb, psadhukhan ! test/jdk/java/awt/FontClass/DrawStringWithInfiniteXform.java Changeset: 0488ebdf Author: Aleksey Shipilev Date: 2021-11-02 06:38:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0488ebdf14dacfa79d98de16ed949c813dd88701 8276105: C2: Conv(D|F)2(I|L)Nodes::Ideal should handle rounding correctly Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/convertnode.cpp Changeset: 9bf31652 Author: Masanori Yano Committer: Alan Bateman Date: 2021-11-02 06:44:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9bf31652cbe8eb2699babe5e52e62ea1f1578588 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc Reviewed-by: alanb ! src/java.base/share/classes/java/io/DataOutput.java ! src/java.base/share/classes/java/io/RandomAccessFile.java Changeset: 92be9d8c Author: Ludvig Janiuk Committer: Sean Coffey Date: 2021-11-02 09:46:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92be9d8c535274eea4edd06273e6d7811f6bb113 8276236: Table headers missing in Formatter api docs Reviewed-by: coffeys, iris ! src/java.base/share/classes/java/util/Formatter.java Changeset: b7a06be9 Author: Aleksey Shipilev Date: 2021-11-02 10:26:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7a06be98d3057dac4adbb7f4071ac62cf88fe52 8252990: Intrinsify Unsafe.storeStoreFence Reviewed-by: dholmes, thartmann, whuang ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 9971a2ca Author: Severin Gehwolf Date: 2021-11-02 10:39:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9971a2cab3892a17f3fd39243df5ecfff5b9f108 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) Reviewed-by: hseigel, mchung ! src/java.base/linux/classes/jdk/internal/platform/CgroupV1Metrics.java ! src/java.base/linux/classes/jdk/internal/platform/CgroupV1MetricsImpl.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java ! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java ! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java Changeset: 8630f55e Author: Hannes Walln?fer Date: 2021-11-02 12:10:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8630f55ed7a0483ec5dcb13a7f53b52bc4ab6fc6 8275406: Add copy-to-clipboard feature to snippet UI Reviewed-by: erikj, jjg ! make/CompileInterimLangtools.gmk ! make/modules/jdk.javadoc/Java.gmk ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/copy.svg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: 5b4e3986 Author: Yoshiki Sato Committer: Sean Coffey Date: 2021-11-02 13:02:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b4e39863dbc0d61e91675261dd6887f704ab868 8275766: (tz) Update Timezone Data to 2021e 8275849: TestZoneInfo310.java fails with tzdata2021e Reviewed-by: naoto, iris, erikj, coffeys ! make/data/tzdata/VERSION ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/northamerica ! src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java Changeset: b889f2a8 Author: Thomas Stuefe Date: 2021-11-02 13:04:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b889f2a88a5e182d2424b741d8fedf2c784442f1 8276175: codestrings.validate_vm gtest still broken on ppc64 after JDK-8276046 Reviewed-by: mdoerr ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: cd778f5b Author: Alexander Zuev Date: 2021-11-02 13:23:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd778f5b049d52b68ab5872aad5f81e86e1718f7 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on Windows Reviewed-by: prr ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Debug/DumpOnKey/DumpOnKey.java Changeset: 495c828a Author: Naoto Sato Date: 2021-11-02 16:08:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/495c828ae95205885b091dde795b517ba332a2b1 8276188: Clarify "default charset" descriptions in String class Reviewed-by: iris, joehw ! src/java.base/share/classes/java/lang/String.java Changeset: fa4ce824 Author: Brian Burkhalter Date: 2021-11-02 16:27:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa4ce824a39264e765b8236ee58b1f28faa371e0 8276260: (se) Remove java/nio/channels/Selector/Wakeup.java from ProblemList (win) Reviewed-by: alanb ! test/jdk/ProblemList.txt Changeset: 8fc16f16 Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-02 16:32:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8fc16f1605b396bfb9265a97bc126d435d6d5951 8275729: Qualified method names in CodeHeap Analytics Reviewed-by: yyang, thartmann ! src/hotspot/share/code/codeHeapState.cpp + test/hotspot/jtreg/serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java Changeset: 01105d69 Author: Daniel D. Daugherty Date: 2021-11-02 16:50:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01105d6985b39d4064b9066eab3612da5a401685 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java Reviewed-by: bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: 6a04899b Author: Markus Karg Committer: Lance Andersen Date: 2021-11-02 18:06:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6a04899ba1a62f52f7e28cc2ed72bdca115e6562 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB Reviewed-by: lancea ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: bb92fb02 Author: Alex Menkov Date: 2021-11-02 21:57:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb92fb02ca8c5795989065a9037748dc39ed77db 8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string Reviewed-by: sspitsyn, lmesnik ! test/jdk/sun/tools/jps/JpsHelper.java Changeset: 2b02b6f5 Author: Guoxiong Li Date: 2021-11-03 01:57:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b02b6f513b062261195ca1edd059d16abb7bec6 8274942: AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java + test/langtools/tools/javac/annotations/typeAnnotations/NestTypeAnnotation.java Changeset: 87b926eb Author: sunguoyun Committer: Igor Veresov Date: 2021-11-03 05:51:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87b926ebb7f1e341da858f7a9892377586abc026 8275086: compiler/c2/irTests/TestPostParseCallDevirtualization.java fails when compiler1 is disabled Reviewed-by: iveresov ! test/hotspot/jtreg/compiler/c2/irTests/TestPostParseCallDevirtualization.java Changeset: 7439b59b Author: Christian Hagedorn Date: 2021-11-03 08:44:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7439b59b5a6816269b16d210ef10779fc9def8e2 8276044: ciReplay: C1 does not dump a replay file when using DumpReplay as compile command option Reviewed-by: kvn, thartmann, dlong ! src/hotspot/share/c1/c1_Compilation.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/TestDumpReplayCommandLine.java Changeset: 465d350d Author: Aleksey Shipilev Date: 2021-11-03 09:06:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/465d350d0b3cac277a58b9f8ece196c1cde68e80 8276157: C2: Compiler stack overflow during escape analysis on Linux x86_32 Reviewed-by: kvn, thartmann ! src/hotspot/os_cpu/linux_x86/globals_linux_x86.hpp Changeset: 61506336 Author: Pavel Rappo Date: 2021-11-03 10:07:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/615063364ab6bdd3fa83401745e05b45e13eacdb 8276348: Use blessed modifier order in java.base Reviewed-by: dfuchs, darcy, iris, rriggs, martin ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/lang/Process.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/WeakPairMap.java ! src/java.base/share/classes/java/lang/invoke/AbstractConstantGroup.java ! src/java.base/share/classes/java/lang/invoke/CallSite.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/util/ImmutableCollections.java ! src/java.base/share/classes/jdk/internal/icu/util/CodePointTrie.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java ! src/java.base/share/classes/jdk/internal/logger/SimpleConsoleLogger.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLHandshake.java Changeset: a316c06e Author: Zhengyu Gu Date: 2021-11-03 12:08:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a316c06e03e06b86ceca376cf20dcb9c526905f5 8275730: Relax memory constraint on MultiThreadedRefCounter Reviewed-by: mgronlun, minqi ! src/hotspot/share/jfr/utilities/jfrRefCountPointer.hpp Changeset: be1ca2bd Author: Hamlin Li Date: 2021-11-03 12:39:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/be1ca2bd201170b0d280030a2aae4c8d1da9f4af 8276298: G1: Remove unused G1SegmentedArrayBufferList::add Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp Changeset: 87318460 Author: Daniel D. Daugherty Date: 2021-11-03 15:02:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87318460012d3fa1a8d3e8749d7a20328b27b826 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 Reviewed-by: alanb ! test/jdk/ProblemList.txt Changeset: 61cb4bc6 Author: Tobias Holenstein Committer: Christian Hagedorn Date: 2021-11-03 15:31:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b 8276036: The value of full_count in the message of insufficient codecache is wrong Reviewed-by: kvn, dlong, thartmann, chagedorn ! src/hotspot/share/code/codeCache.cpp Changeset: 724bf3be Author: Aleksey Shipilev Date: 2021-11-03 15:41:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/724bf3be1458f7da502f8772be6151bed826b4f7 8275604: Zero: Reformat opclabels_data Reviewed-by: adinn, zgu ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 0ef8cbe3 Author: Phil Race Date: 2021-11-03 16:22:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ef8cbe32540814d4c0be9c7b0f78486408657a7 8276385: Re-run blessed-modifier-order script on java.desktop and jdk.accessibility Reviewed-by: serb ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifInteroperabilityTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifParentTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/FaxTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/GeoTIFFTagSet.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListColor.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityListenerList.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventID.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventQueueMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java Changeset: 7115892f Author: Daniel Fuchs Date: 2021-11-03 16:23:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7115892f96a5a57ce9d37602038b787d19da5d81 8276401: Use blessed modifier order in java.net.http Reviewed-by: prappo, rriggs ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/DebugLogger.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/FlowTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/MinimalFuture.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SequentialScheduler.java Changeset: 684edbb4 Author: Brian Burkhalter Date: 2021-11-03 16:55:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/684edbb4c884cbc3e05118e4bc9808b5d5b71a74 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) Reviewed-by: alanb ! src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java Changeset: c7f070f5 Author: Jakob Cornell Committer: Chris Plummer Date: 2021-11-03 18:18:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7f070f5f17dad661cc3296f2e3cd7a1cd5fc742 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" Reviewed-by: cjplummer, iklam ! test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java Changeset: 32895ac6 Author: Ivan ?ipka Committer: Mark Sheppard Date: 2021-11-03 19:30:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 Reviewed-by: bpb, msheppar + out ! test/jdk/ProblemList.txt Changeset: f3320d2f Author: Joe Darcy Date: 2021-11-03 21:20:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f3320d2fbd28349fa5eab3ea0da0ff0a3ef54c62 8276588: Change "ccc" to "CSR" in HotSpot sources Reviewed-by: dcubed, kbarrett ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 0ab910d6 Author: Jie Fu Date: 2021-11-03 22:45:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ab910d626a05106e1366438aeb5b16e16374c2f 8276066: Reset LoopPercentProfileLimit for x86 due to suboptimal performance Reviewed-by: thartmann, kvn ! src/hotspot/cpu/x86/c2_globals_x86.hpp + test/micro/org/openjdk/bench/vm/compiler/LoopUnroll.java Changeset: ce8c7670 Author: Claes Redestad Date: 2021-11-03 22:57:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce8c76700ba854f43c48d32b068b30e7d78d9d1e 8276220: Reduce excessive allocations in DateTimeFormatter Reviewed-by: scolebourne, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/java/time/format/DateTimePrintContext.java ! test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java + test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java Changeset: 603bba28 Author: Yumin Qi Date: 2021-11-03 23:16:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/603bba282a089928fd23f8da23a7c1b2d52944ef 8271420: Extend CDS custom loader support to Windows platform Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/classListParser.cpp ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/CustomAppLoader.java ! test/lib/jdk/test/lib/Platform.java Changeset: 558ee40a Author: Yasumasa Suenaga Date: 2021-11-04 04:34:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/558ee40a4ac158e5be8269c87b7e18af77dd14c5 8276615: Update CR number of some tests in ProblemList-zgc.txt Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: fb0be81f Author: Aleksey Shipilev Date: 2021-11-04 08:03:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb0be81f0148d9aea73321a0c2bd83b2e477d952 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence Reviewed-by: psandoz, aph, dholmes ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 9eadcbb4 Author: Aleksey Shipilev Date: 2021-11-04 08:08:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9eadcbb47e902f42d933ba68e24f2bfb0ee20915 8276217: Harmonize StrictMath intrinsics handling Reviewed-by: aph, kvn ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp Changeset: a1f4c428 Author: Christian Hagedorn Date: 2021-11-04 08:53:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a1f4c428ba1b78a4e18afb87c94a5c731a5aa706 8276227: ciReplay: SIGSEGV if classfile for replay compilation is not present after JDK-8275868 Reviewed-by: kvn, thartmann, dlong ! src/hotspot/share/ci/ciReplay.cpp + test/hotspot/jtreg/compiler/ciReplay/TestNoClassFile.java Changeset: c62b3476 Author: Aleksey Shipilev Date: 2021-11-04 09:03:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c62b3476ce12cea633abead0d6376ea0a05f92f9 8276623: JDK-8275650 accidentally pushed "out" file Reviewed-by: tschatzl, dholmes - out Changeset: 3613ce7c Author: Aleksey Shipilev Date: 2021-11-04 10:23:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3613ce7c7d5bc8b7d603e1cf6a123588339aed3f 8275586: Zero: Simplify interpreter initialization Reviewed-by: aph, adinn ! src/hotspot/cpu/zero/vm_version_zero.cpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: ee499632 Author: Julia Boes Date: 2021-11-04 11:31:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ee499632586eabb3dab209645d5b9c781a09034b 8275534: com.sun.net.httpserver.BasicAuthenticator should check whether "realm" is a quoted string Reviewed-by: michaelm, dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java + src/jdk.httpserver/share/classes/sun/net/httpserver/Utils.java + test/jdk/com/sun/net/httpserver/BasicAuthenticatorRealm.java ! test/jdk/com/sun/net/httpserver/bugs/BasicAuthenticatorExceptionCheck.java Changeset: 7de653e4 Author: Hamlin Li Date: 2021-11-04 12:31:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7de653e428ee38339ec38533659b23a52e275f3f 8276301: G1: Refine implementation of G1CardSetFreePool::memory_sizes() Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp Changeset: 19075b3f Author: Hannes Walln?fer Date: 2021-11-04 13:06:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/19075b3f6b21f6d3b0624ef8e835b3cfc53228de 8275788: Create code element with suitable attributes for code snippets Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: a6fa6ed1 Author: Per Liden Date: 2021-11-04 13:47:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6fa6ed1edc6f473a7fea1fa00edd467ab778983 8268779: ZGC: runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with "OutOfMemoryError: Java heap space" Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/zDriver.cpp Changeset: 5acff753 Author: Evgeny Astigeevich Committer: Vladimir Kozlov Date: 2021-11-04 15:01:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5acff75379a4ad0acfcfc6a64fcc4b588ef048c7 8276429: CodeHeapState::print_names() fails with "assert(klass->is_loader_alive()) failed: must be alive" Reviewed-by: kvn ! src/hotspot/share/code/codeHeapState.cpp Changeset: 49b7b2ea Author: Magnus Ihse Bursie Date: 2021-11-04 15:06:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/49b7b2ea0971fe99567bdbd962d63b90ff2eeefd 8276640: Use blessed modifier order in jfr code Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/FilePurger.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PrivateAccess.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java Changeset: afb502e2 Author: Aleksey Shipilev Date: 2021-11-04 15:41:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/afb502e28a81183cef76a7e60fc052e8cad3afe3 8276550: Use SHA256 hash in build.tools.depend.Depend Reviewed-by: adinn, aph, andrew, ihse ! make/jdk/src/classes/build/tools/depend/Depend.java Changeset: bf4ddf9c Author: Pavel Rappo Date: 2021-11-04 15:51:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf4ddf9cb7408db321e7fd73600a5a9a85ca49eb 8276338: Minor improve of wording for String.to(Lower|Upper)Case Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/lang/String.java Changeset: b57715a1 Author: Pavel Rappo Date: 2021-11-04 15:56:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b57715a117d9b7f79fcf4fec3b8f369b6aa42598 8276573: Use blessed modifier order in jdk.javadoc Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java Changeset: 7bb21733 Author: Brian Burkhalter Date: 2021-11-04 16:33:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7bb2173383bc1c0d55564d31303a547957d87a15 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly Reviewed-by: alanb ! test/jdk/ProblemList.txt ! test/jdk/java/nio/channels/FileChannel/LargeGatheringWrite.java Changeset: 1533b819 Author: Magnus Ihse Bursie Date: 2021-11-04 17:02:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1533b8191bed9d65ab4af03945584d8b2276d828 8276629: Use blessed modifier order in core-libs code Reviewed-by: dholmes, aefimov, dfuchs, mchung, iris ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/java.rmi/share/classes/java/rmi/server/LoaderHandler.java ! src/java.rmi/share/classes/java/rmi/server/RMISocketFactory.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObject.java ! src/java.rmi/share/classes/java/rmi/server/RemoteRef.java ! src/java.rmi/share/classes/java/rmi/server/RemoteStub.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java ! src/java.rmi/share/classes/sun/rmi/transport/ObjectTable.java ! src/java.rmi/share/classes/sun/rmi/transport/Target.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/jdk.dynalink/share/classes/jdk/dynalink/BiClassValue.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Annotation.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Dependencies.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ResourceFilter.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContext.java ! src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContextFactory.java Changeset: 99d4b07c Author: Ludvig Janiuk Committer: Mandy Chung Date: 2021-11-04 17:26:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99d4b07cddec05428e4d578ba6f494f51b92e841 8276649: MethodHandles.Lookup docs: replace the table in the cross-module access check section with list Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 2b5a32c7 Author: Zhengyu Gu Date: 2021-11-04 19:40:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b5a32c73f22c69d7ccedac761af1dbb4a7f297d 8275718: Relax memory constraint on exception counter updates Reviewed-by: dholmes, minqi ! src/hotspot/share/utilities/exceptions.cpp Changeset: 81203efe Author: Magnus Ihse Bursie Date: 2021-11-04 19:44:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81203efe411320ff4e390605f980d14e7f70252f 8276655: Use blessed modifier order in SCTP Reviewed-by: alanb, dfuchs ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/AssociationChange.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/PeerAddrChange.java Changeset: dcf36f87 Author: Dean Long Date: 2021-11-04 19:52:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dcf36f87f87d52490c1f0434c2fca99fc8fd90a2 8275670: ciReplay: java.lang.NoClassDefFoundError when trying to load java/lang/invoke/LambdaForm$MH Reviewed-by: kvn, chagedorn ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp + test/hotspot/jtreg/compiler/ciReplay/TestLambdas.java Changeset: 7e87f946 Author: Ludvig Janiuk Committer: Mandy Chung Date: 2021-11-04 20:46:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e87f946cedf93f19c38fd596039a16394c03ea4 8276652: Missing row headers in MethodHandles.Lookup docs Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 8ec80c4b Author: Ludvig Janiuk Committer: Naoto Sato Date: 2021-11-04 21:06:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8ec80c4bc1c3169963137b5a16a1b787540a3589 8276653: Missing row headers in j.l.Character docs Reviewed-by: naoto ! src/java.base/share/classes/java/lang/Character.java Changeset: 7b1916ef Author: Alisen Chung Committer: Phil Race Date: 2021-11-04 21:53:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b1916efda95a46439cf42e006593361d12a8823 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on macOs Reviewed-by: prr ! test/jdk/ProblemList.txt Changeset: e21b5c7b Author: Mandy Chung Date: 2021-11-04 23:51:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e21b5c7b3781430ecf568e7f5c89ef3391e06d9e 8276650: GenGraphs does not produce deterministic output Reviewed-by: iris ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java ! test/langtools/tools/jdeps/modules/DotFileTest.java Changeset: 9ad4d3d0 Author: Sandhya Viswanathan Date: 2021-11-05 03:30:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ad4d3d06bb356436d69af07726ef6727c500f59 8276025: Hotspot's libsvml.so may conflict with user dependency Reviewed-by: kvn, erikj, psandoz, ihse ! make/modules/jdk.incubator.vector/Lib.gmk ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp = src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_acos_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_asin_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cbrt_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_expm1_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log10_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log1p_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sinh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tanh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_acos_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_asin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cbrt_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cos_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_expm1_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log10_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log1p_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_pow_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sinh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tan_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tanh_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_acos_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_asin_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan2_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_cbrt_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_cosh_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_exp_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_expm1_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_log10_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_atan_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_cbrt_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_exp_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_expm1_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log10_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log1p_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log_linux_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cbrt_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_expm1_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_pow_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sinh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tanh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cbrt_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_expm1_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_pow_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sinh_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tanh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_acos_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_asin_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan2_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_cbrt_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_cosh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_exp_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_expm1_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_hypot_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log10_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log1p_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_pow_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_sinh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_tan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_tanh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_acos_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_asin_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan2_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_cbrt_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_cosh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_exp_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_expm1_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log10_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log1p_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_sinh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_tanh_windows_x86.S ! test/jdk/jdk/incubator/vector/ImageTest.java = test/jdk/jdk/incubator/vector/LoadJsvmlTest.java Changeset: 396132ff Author: Jaikiran Pai Date: 2021-11-05 03:44:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/396132ff1e56463ad195cac5c9ac8e2eac5a16e8 8275509: ModuleDescriptor.hashCode isn't reproducible across builds Reviewed-by: alanb, ihse ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java + test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java Changeset: 8e17ce00 Author: Ioi Lam Date: 2021-11-05 04:37:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8e17ce00316a765bbedefc34dc5898ba4f3f2144 8275185: Remove dead code and clean up jvmstat LocalVmManager Reviewed-by: cjplummer, redestad, kevinw ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java Changeset: 7281861e Author: Thomas Stuefe Date: 2021-11-05 05:15:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7281861e0662e6c51507066a1f12673a236c7491 8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 Reviewed-by: mchung, coleenp, dholmes ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp - src/hotspot/share/oops/reflectionAccessorImplKlassHelper.cpp - src/hotspot/share/oops/reflectionAccessorImplKlassHelper.hpp ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java - test/hotspot/jtreg/serviceability/dcmd/vm/ShowReflectionTargetTest.java Changeset: 96c396b7 Author: Ningsheng Jian Date: 2021-11-05 07:45:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96c396b701e290fc3e1124b1c862b41e02e9c1d9 8276151: AArch64: Incorrect result for double to int vector conversion Reviewed-by: aph, psandoz ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! test/hotspot/jtreg/compiler/vectorapi/VectorCastShape128Test.java ! test/hotspot/jtreg/compiler/vectorapi/VectorCastShape64Test.java Changeset: 323d2017 Author: Leo Korinth Date: 2021-11-05 09:25:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/323d2017959dc96d25eaa1aad6404586099c237e 8275506: Rename allocated_on_stack to allocated_on_stack_or_embedded Reviewed-by: stuefe ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/utilities/growableArray.cpp ! test/hotspot/gtest/utilities/test_growableArray.cpp Changeset: 3c0faa73 Author: Leo Korinth Date: 2021-11-05 09:42:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3c0faa73522bd004b66cb9e477f43e15a29842e6 8276173: Clean up and remove unneeded casts in HeapDumper Reviewed-by: coleenp, hseigel ! src/hotspot/share/services/heapDumper.cpp Changeset: d95299a4 Author: Patrick Concannon Date: 2021-11-05 10:39:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d95299a4d751449816ad2a88359f1e48e9608246 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java Reviewed-by: dfuchs, alanb, vtewari ! test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java ! test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java Changeset: a4e8d061 Author: duke Date: 2021-11-05 11:00:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a4e8d061d80cf9be501c9c700450891a445e7767 Automatic merge of jdk:master into master Changeset: 330a9f8c Author: duke Date: 2021-11-05 11:01:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/330a9f8c53b62e5f11775b2842709c77835a4971 Automatic merge of master into foreign-memaccess+abi ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/runtime/globals.hpp From duke at openjdk.java.net Fri Nov 5 11:19:40 2021 From: duke at openjdk.java.net (duke) Date: Fri, 5 Nov 2021 11:19:40 GMT Subject: git: openjdk/panama-foreign: master: 95 new changesets Message-ID: Changeset: c0cda1db Author: Ilarion Nakonechnyy Committer: Weijun Wang Date: 2021-10-29 11:37:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0cda1db4fe74b86faa12136336bdf98c96758d2 8273026: Slow LoginContext.login() on multi threading application Reviewed-by: weijun ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java ! test/jdk/javax/security/auth/spi/Loader.java ! test/jdk/javax/security/auth/spi/SecondLoginModule.java Changeset: 4c3491bf Author: Alexander Zuev Date: 2021-10-29 11:44:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c3491bfa5f296b80c56a37cb4fffd6497323ac2 8017175: [TESTBUG] javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java Changeset: 8cc59509 Author: Sean Mullan Date: 2021-10-29 12:42:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8cc59509fe7c01c9032275798ccd1531eb8f2e9f 8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and getExtendedKeyUsage do not throw CertificateParsingException if extension is unparseable Reviewed-by: weijun ! src/java.base/share/classes/sun/security/x509/CertificateExtensions.java + src/java.base/share/classes/sun/security/x509/UnparseableExtension.java ! src/java.base/share/classes/sun/security/x509/X509CertImpl.java + test/jdk/java/security/cert/X509Certificate/GetUnparseableExtensions.java Changeset: a1ec4f96 Author: Alexander Zvegintsev Date: 2021-10-29 13:05:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a1ec4f961841fe0b580c32b37c77e3906ba66966 6854300: [TEST_BUG] java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in jdk6u14 & jdk7 Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java Changeset: d6d82f52 Author: Thomas Stuefe Date: 2021-10-29 13:54:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6d82f52d4a4fac037ee9424503f8b7f11a61c40 8275608: runtime/Metaspace/elastic/TestMetaspaceAllocationMT2 too slow Reviewed-by: mbaesken, shade ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestArena.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestManyArenasManyThreads.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestWithThreads.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocator.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocatorThread.java Changeset: 5facaa24 Author: Brian Burkhalter Date: 2021-10-29 16:12:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5facaa243aef6ad00cf71a047d0325710ce1f0a8 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer Reviewed-by: lancea, iris, alanb ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Changeset: 13265f99 Author: Brian Burkhalter Date: 2021-10-29 16:13:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13265f9901ab8334bbe1e7a571a9c5f386275dbf 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 Reviewed-by: rriggs, naoto ! test/jdk/java/io/File/GetXSpace.java Changeset: cef9db9a Author: Yumin Qi Date: 2021-10-29 16:15:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cef9db9a69061d51630e40b94ceba4b4bf03a0ce 8276039: Remove unnecessary qualifications of java_lang_Class:: Reviewed-by: mikael, iklam ! src/hotspot/share/classfile/javaClasses.cpp Changeset: fe6a2020 Author: Jakob Cornell Committer: Chris Plummer Date: 2021-10-29 17:50:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe6a2020873fe1eb8d4236dc1db3008f485f3195 8271356: Modify jdb to treat an empty command as a repeat of the previous command Reviewed-by: cjplummer, iklam ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003a.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001a.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbCommand.java Changeset: 5021a12c Author: Igor Veresov Date: 2021-10-29 18:03:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5021a12ceada3192e81e2c06b556e7c80cd6cf31 8274855: vectorapi tests failing with assert(!vbox->is_Phi()) failed Reviewed-by: kvn ! src/hotspot/share/opto/vector.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 5bbc8d3c Author: Alex Menkov Date: 2021-10-29 21:38:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5bbc8d3cb2ce487b367ee1a621d78699c9b30100 8274621: NullPointerException because listenAddress[0] is null Reviewed-by: sspitsyn, lmesnik, cjplummer ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: 68756782 Author: Sergey Bylokhov Date: 2021-10-30 09:03:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/687567822a5380fb7d8c5b54ae548b2a5c848187 8273831: PrintServiceLookup spawns 2 threads in the current classloader, getting orphaned Reviewed-by: aivanov ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java + test/jdk/javax/print/PrintServiceLookup/FlushCustomClassLoader.java Changeset: b7104ba9 Author: Alexander Zuev Date: 2021-10-30 10:01:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7104ba9a9006ab65e08ea9d7db22e72611ed07c 8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: bf2e9ee9 Author: Man Cao Date: 2021-10-31 04:58:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf2e9ee9d321ed289466b2410f12ad10504d01a2 8275080: G1CollectedHeap::expand() returns the wrong value Co-authored-by: Jonathan Joo Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 158831e4 Author: Thomas Stuefe Date: 2021-11-01 05:13:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/158831e4c3fa637905fda6f28e9adf8e957b9e55 8274320: os::fork_and_exec() should be using posix_spawn Reviewed-by: mdoerr, dholmes ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/vmError.cpp Changeset: 5bb1992b Author: Christian Hagedorn Date: 2021-11-01 08:22:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5bb1992b8408a0d196b1afa308bc00d007458dbd 8275868: ciReplay: Inlining fails with "unloaded signature classes" due to wrong protection domains Reviewed-by: kvn, dlong, thartmann ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciReplay.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/DumpReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java Changeset: dbf5100d Author: Zhengyu Gu Date: 2021-11-01 12:17:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dbf5100dd705fbe4a3aeae49405ca541d581f106 8276201: Shenandoah: Race results degenerated GC to enter wrong entry point Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp Changeset: 89ade1d7 Author: Aleksey Shipilev Date: 2021-11-01 12:30:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/89ade1d7e88ee005c3fd2136d84e298d94f9a67c 8273416: C2: assert(false) failed: bad AD file after JDK-8252372 with UseSSE={0,1} Reviewed-by: kvn, roland ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/share/opto/castnode.hpp Changeset: 4ac8403f Author: Erik Gahlin Date: 2021-11-01 12:33:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ac8403f9a4cedcb5d56bcd34a6bbfa51d67ca18 8276218: JFR: Clean up jdk.jfr.dcmd Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java Changeset: f55e68c9 Author: Patricio Chilano Mateo Date: 2021-11-01 15:27:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f55e68c92924bb70471a4851f616d4c3065ffa92 8275950: Use only _thread_in_vm in ~ThreadBlockInVMPreprocess() Reviewed-by: dholmes, dcubed ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepoint.hpp Changeset: c8abe354 Author: Leo Korinth Date: 2021-11-01 15:37:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c8abe354c1ddc988ff54b9a96a4a825e2aa70f4b 8276121: G1: Remove unused and uninitialized _g1h in g1SATBMarkQueueSet.hpp Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1SATBMarkQueueSet.hpp Changeset: e265f838 Author: Thomas Schatzl Date: 2021-11-01 16:48:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e265f83858b84451258677f130f98be5375a417a 8276107: Preventive collections trigger before maxing out heap Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1Policy.cpp Changeset: 97715440 Author: Patrick Concannon Date: 2021-11-01 17:11:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/977154400be786c500f36ba14188bff79db57075 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations Reviewed-by: alanb, dfuchs, vtewari ! src/java.base/share/classes/java/net/DatagramSocketImpl.java ! src/java.base/share/classes/java/net/NetMulticastSocket.java + test/jdk/java/net/DatagramSocket/OldDatagramSocketImplTest.java Changeset: 99b7b95e Author: Zhengyu Gu Date: 2021-11-01 19:38:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99b7b95e014da6e491ba7adfd21de53d6ae166fe 8276205: Shenandoah: CodeCache_lock should always be held for initializing code cache iteration Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Changeset: 47e7a425 Author: Alisen Chung Committer: Alexander Zuev Date: 2021-11-01 22:29:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47e7a42594f1c36f71cdf4d383080bf8d616b7e7 8262945: [macos] Regression Manual Test for Key Events Fails Reviewed-by: prr, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m Changeset: 2eafa036 Author: Pavel Rappo Date: 2021-11-01 22:50:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2eafa036c03d3e8f3dba8f67dd37b484874dc3d3 8276234: Trivially clean up locale-related code Reviewed-by: redestad, naoto, iris ! src/java.base/share/classes/java/time/chrono/JapaneseChronology.java ! src/java.base/share/classes/sun/util/locale/BaseLocale.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java Changeset: acceffcb Author: Phil Race Date: 2021-11-02 02:49:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/acceffcbf73aa4416c487f890f3ca65e55e47164 8273704: DrawStringWithInfiniteXform.java failed : drawString with InfiniteXform transform takes long time Reviewed-by: serb, psadhukhan ! test/jdk/java/awt/FontClass/DrawStringWithInfiniteXform.java Changeset: 0488ebdf Author: Aleksey Shipilev Date: 2021-11-02 06:38:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0488ebdf14dacfa79d98de16ed949c813dd88701 8276105: C2: Conv(D|F)2(I|L)Nodes::Ideal should handle rounding correctly Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/convertnode.cpp Changeset: 9bf31652 Author: Masanori Yano Committer: Alan Bateman Date: 2021-11-02 06:44:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9bf31652cbe8eb2699babe5e52e62ea1f1578588 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc Reviewed-by: alanb ! src/java.base/share/classes/java/io/DataOutput.java ! src/java.base/share/classes/java/io/RandomAccessFile.java Changeset: 92be9d8c Author: Ludvig Janiuk Committer: Sean Coffey Date: 2021-11-02 09:46:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92be9d8c535274eea4edd06273e6d7811f6bb113 8276236: Table headers missing in Formatter api docs Reviewed-by: coffeys, iris ! src/java.base/share/classes/java/util/Formatter.java Changeset: b7a06be9 Author: Aleksey Shipilev Date: 2021-11-02 10:26:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7a06be98d3057dac4adbb7f4071ac62cf88fe52 8252990: Intrinsify Unsafe.storeStoreFence Reviewed-by: dholmes, thartmann, whuang ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 9971a2ca Author: Severin Gehwolf Date: 2021-11-02 10:39:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9971a2cab3892a17f3fd39243df5ecfff5b9f108 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) Reviewed-by: hseigel, mchung ! src/java.base/linux/classes/jdk/internal/platform/CgroupV1Metrics.java ! src/java.base/linux/classes/jdk/internal/platform/CgroupV1MetricsImpl.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java ! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java ! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java Changeset: 8630f55e Author: Hannes Walln?fer Date: 2021-11-02 12:10:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8630f55ed7a0483ec5dcb13a7f53b52bc4ab6fc6 8275406: Add copy-to-clipboard feature to snippet UI Reviewed-by: erikj, jjg ! make/CompileInterimLangtools.gmk ! make/modules/jdk.javadoc/Java.gmk ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/copy.svg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: 5b4e3986 Author: Yoshiki Sato Committer: Sean Coffey Date: 2021-11-02 13:02:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b4e39863dbc0d61e91675261dd6887f704ab868 8275766: (tz) Update Timezone Data to 2021e 8275849: TestZoneInfo310.java fails with tzdata2021e Reviewed-by: naoto, iris, erikj, coffeys ! make/data/tzdata/VERSION ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/northamerica ! src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java Changeset: b889f2a8 Author: Thomas Stuefe Date: 2021-11-02 13:04:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b889f2a88a5e182d2424b741d8fedf2c784442f1 8276175: codestrings.validate_vm gtest still broken on ppc64 after JDK-8276046 Reviewed-by: mdoerr ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: cd778f5b Author: Alexander Zuev Date: 2021-11-02 13:23:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd778f5b049d52b68ab5872aad5f81e86e1718f7 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on Windows Reviewed-by: prr ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Debug/DumpOnKey/DumpOnKey.java Changeset: 495c828a Author: Naoto Sato Date: 2021-11-02 16:08:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/495c828ae95205885b091dde795b517ba332a2b1 8276188: Clarify "default charset" descriptions in String class Reviewed-by: iris, joehw ! src/java.base/share/classes/java/lang/String.java Changeset: fa4ce824 Author: Brian Burkhalter Date: 2021-11-02 16:27:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa4ce824a39264e765b8236ee58b1f28faa371e0 8276260: (se) Remove java/nio/channels/Selector/Wakeup.java from ProblemList (win) Reviewed-by: alanb ! test/jdk/ProblemList.txt Changeset: 8fc16f16 Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-02 16:32:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8fc16f1605b396bfb9265a97bc126d435d6d5951 8275729: Qualified method names in CodeHeap Analytics Reviewed-by: yyang, thartmann ! src/hotspot/share/code/codeHeapState.cpp + test/hotspot/jtreg/serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java Changeset: 01105d69 Author: Daniel D. Daugherty Date: 2021-11-02 16:50:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01105d6985b39d4064b9066eab3612da5a401685 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java Reviewed-by: bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: 6a04899b Author: Markus Karg Committer: Lance Andersen Date: 2021-11-02 18:06:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6a04899ba1a62f52f7e28cc2ed72bdca115e6562 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB Reviewed-by: lancea ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: bb92fb02 Author: Alex Menkov Date: 2021-11-02 21:57:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb92fb02ca8c5795989065a9037748dc39ed77db 8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string Reviewed-by: sspitsyn, lmesnik ! test/jdk/sun/tools/jps/JpsHelper.java Changeset: 2b02b6f5 Author: Guoxiong Li Date: 2021-11-03 01:57:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b02b6f513b062261195ca1edd059d16abb7bec6 8274942: AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java + test/langtools/tools/javac/annotations/typeAnnotations/NestTypeAnnotation.java Changeset: 87b926eb Author: sunguoyun Committer: Igor Veresov Date: 2021-11-03 05:51:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87b926ebb7f1e341da858f7a9892377586abc026 8275086: compiler/c2/irTests/TestPostParseCallDevirtualization.java fails when compiler1 is disabled Reviewed-by: iveresov ! test/hotspot/jtreg/compiler/c2/irTests/TestPostParseCallDevirtualization.java Changeset: 7439b59b Author: Christian Hagedorn Date: 2021-11-03 08:44:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7439b59b5a6816269b16d210ef10779fc9def8e2 8276044: ciReplay: C1 does not dump a replay file when using DumpReplay as compile command option Reviewed-by: kvn, thartmann, dlong ! src/hotspot/share/c1/c1_Compilation.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/TestDumpReplayCommandLine.java Changeset: 465d350d Author: Aleksey Shipilev Date: 2021-11-03 09:06:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/465d350d0b3cac277a58b9f8ece196c1cde68e80 8276157: C2: Compiler stack overflow during escape analysis on Linux x86_32 Reviewed-by: kvn, thartmann ! src/hotspot/os_cpu/linux_x86/globals_linux_x86.hpp Changeset: 61506336 Author: Pavel Rappo Date: 2021-11-03 10:07:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/615063364ab6bdd3fa83401745e05b45e13eacdb 8276348: Use blessed modifier order in java.base Reviewed-by: dfuchs, darcy, iris, rriggs, martin ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/lang/Process.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/WeakPairMap.java ! src/java.base/share/classes/java/lang/invoke/AbstractConstantGroup.java ! src/java.base/share/classes/java/lang/invoke/CallSite.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/util/ImmutableCollections.java ! src/java.base/share/classes/jdk/internal/icu/util/CodePointTrie.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java ! src/java.base/share/classes/jdk/internal/logger/SimpleConsoleLogger.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLHandshake.java Changeset: a316c06e Author: Zhengyu Gu Date: 2021-11-03 12:08:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a316c06e03e06b86ceca376cf20dcb9c526905f5 8275730: Relax memory constraint on MultiThreadedRefCounter Reviewed-by: mgronlun, minqi ! src/hotspot/share/jfr/utilities/jfrRefCountPointer.hpp Changeset: be1ca2bd Author: Hamlin Li Date: 2021-11-03 12:39:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/be1ca2bd201170b0d280030a2aae4c8d1da9f4af 8276298: G1: Remove unused G1SegmentedArrayBufferList::add Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp Changeset: 87318460 Author: Daniel D. Daugherty Date: 2021-11-03 15:02:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87318460012d3fa1a8d3e8749d7a20328b27b826 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 Reviewed-by: alanb ! test/jdk/ProblemList.txt Changeset: 61cb4bc6 Author: Tobias Holenstein Committer: Christian Hagedorn Date: 2021-11-03 15:31:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b 8276036: The value of full_count in the message of insufficient codecache is wrong Reviewed-by: kvn, dlong, thartmann, chagedorn ! src/hotspot/share/code/codeCache.cpp Changeset: 724bf3be Author: Aleksey Shipilev Date: 2021-11-03 15:41:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/724bf3be1458f7da502f8772be6151bed826b4f7 8275604: Zero: Reformat opclabels_data Reviewed-by: adinn, zgu ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 0ef8cbe3 Author: Phil Race Date: 2021-11-03 16:22:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ef8cbe32540814d4c0be9c7b0f78486408657a7 8276385: Re-run blessed-modifier-order script on java.desktop and jdk.accessibility Reviewed-by: serb ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifInteroperabilityTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifParentTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/FaxTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/GeoTIFFTagSet.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListColor.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityListenerList.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventID.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventQueueMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java Changeset: 7115892f Author: Daniel Fuchs Date: 2021-11-03 16:23:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7115892f96a5a57ce9d37602038b787d19da5d81 8276401: Use blessed modifier order in java.net.http Reviewed-by: prappo, rriggs ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/DebugLogger.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/FlowTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/MinimalFuture.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SequentialScheduler.java Changeset: 684edbb4 Author: Brian Burkhalter Date: 2021-11-03 16:55:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/684edbb4c884cbc3e05118e4bc9808b5d5b71a74 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) Reviewed-by: alanb ! src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java Changeset: c7f070f5 Author: Jakob Cornell Committer: Chris Plummer Date: 2021-11-03 18:18:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7f070f5f17dad661cc3296f2e3cd7a1cd5fc742 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" Reviewed-by: cjplummer, iklam ! test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java Changeset: 32895ac6 Author: Ivan ?ipka Committer: Mark Sheppard Date: 2021-11-03 19:30:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 Reviewed-by: bpb, msheppar + out ! test/jdk/ProblemList.txt Changeset: f3320d2f Author: Joe Darcy Date: 2021-11-03 21:20:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f3320d2fbd28349fa5eab3ea0da0ff0a3ef54c62 8276588: Change "ccc" to "CSR" in HotSpot sources Reviewed-by: dcubed, kbarrett ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 0ab910d6 Author: Jie Fu Date: 2021-11-03 22:45:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ab910d626a05106e1366438aeb5b16e16374c2f 8276066: Reset LoopPercentProfileLimit for x86 due to suboptimal performance Reviewed-by: thartmann, kvn ! src/hotspot/cpu/x86/c2_globals_x86.hpp + test/micro/org/openjdk/bench/vm/compiler/LoopUnroll.java Changeset: ce8c7670 Author: Claes Redestad Date: 2021-11-03 22:57:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce8c76700ba854f43c48d32b068b30e7d78d9d1e 8276220: Reduce excessive allocations in DateTimeFormatter Reviewed-by: scolebourne, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/java/time/format/DateTimePrintContext.java ! test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java + test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java Changeset: 603bba28 Author: Yumin Qi Date: 2021-11-03 23:16:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/603bba282a089928fd23f8da23a7c1b2d52944ef 8271420: Extend CDS custom loader support to Windows platform Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/classListParser.cpp ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/CustomAppLoader.java ! test/lib/jdk/test/lib/Platform.java Changeset: 558ee40a Author: Yasumasa Suenaga Date: 2021-11-04 04:34:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/558ee40a4ac158e5be8269c87b7e18af77dd14c5 8276615: Update CR number of some tests in ProblemList-zgc.txt Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: fb0be81f Author: Aleksey Shipilev Date: 2021-11-04 08:03:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb0be81f0148d9aea73321a0c2bd83b2e477d952 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence Reviewed-by: psandoz, aph, dholmes ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 9eadcbb4 Author: Aleksey Shipilev Date: 2021-11-04 08:08:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9eadcbb47e902f42d933ba68e24f2bfb0ee20915 8276217: Harmonize StrictMath intrinsics handling Reviewed-by: aph, kvn ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp Changeset: a1f4c428 Author: Christian Hagedorn Date: 2021-11-04 08:53:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a1f4c428ba1b78a4e18afb87c94a5c731a5aa706 8276227: ciReplay: SIGSEGV if classfile for replay compilation is not present after JDK-8275868 Reviewed-by: kvn, thartmann, dlong ! src/hotspot/share/ci/ciReplay.cpp + test/hotspot/jtreg/compiler/ciReplay/TestNoClassFile.java Changeset: c62b3476 Author: Aleksey Shipilev Date: 2021-11-04 09:03:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c62b3476ce12cea633abead0d6376ea0a05f92f9 8276623: JDK-8275650 accidentally pushed "out" file Reviewed-by: tschatzl, dholmes - out Changeset: 3613ce7c Author: Aleksey Shipilev Date: 2021-11-04 10:23:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3613ce7c7d5bc8b7d603e1cf6a123588339aed3f 8275586: Zero: Simplify interpreter initialization Reviewed-by: aph, adinn ! src/hotspot/cpu/zero/vm_version_zero.cpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: ee499632 Author: Julia Boes Date: 2021-11-04 11:31:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ee499632586eabb3dab209645d5b9c781a09034b 8275534: com.sun.net.httpserver.BasicAuthenticator should check whether "realm" is a quoted string Reviewed-by: michaelm, dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java + src/jdk.httpserver/share/classes/sun/net/httpserver/Utils.java + test/jdk/com/sun/net/httpserver/BasicAuthenticatorRealm.java ! test/jdk/com/sun/net/httpserver/bugs/BasicAuthenticatorExceptionCheck.java Changeset: 7de653e4 Author: Hamlin Li Date: 2021-11-04 12:31:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7de653e428ee38339ec38533659b23a52e275f3f 8276301: G1: Refine implementation of G1CardSetFreePool::memory_sizes() Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp Changeset: 19075b3f Author: Hannes Walln?fer Date: 2021-11-04 13:06:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/19075b3f6b21f6d3b0624ef8e835b3cfc53228de 8275788: Create code element with suitable attributes for code snippets Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: a6fa6ed1 Author: Per Liden Date: 2021-11-04 13:47:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6fa6ed1edc6f473a7fea1fa00edd467ab778983 8268779: ZGC: runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with "OutOfMemoryError: Java heap space" Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/zDriver.cpp Changeset: 5acff753 Author: Evgeny Astigeevich Committer: Vladimir Kozlov Date: 2021-11-04 15:01:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5acff75379a4ad0acfcfc6a64fcc4b588ef048c7 8276429: CodeHeapState::print_names() fails with "assert(klass->is_loader_alive()) failed: must be alive" Reviewed-by: kvn ! src/hotspot/share/code/codeHeapState.cpp Changeset: 49b7b2ea Author: Magnus Ihse Bursie Date: 2021-11-04 15:06:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/49b7b2ea0971fe99567bdbd962d63b90ff2eeefd 8276640: Use blessed modifier order in jfr code Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/FilePurger.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PrivateAccess.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java Changeset: afb502e2 Author: Aleksey Shipilev Date: 2021-11-04 15:41:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/afb502e28a81183cef76a7e60fc052e8cad3afe3 8276550: Use SHA256 hash in build.tools.depend.Depend Reviewed-by: adinn, aph, andrew, ihse ! make/jdk/src/classes/build/tools/depend/Depend.java Changeset: bf4ddf9c Author: Pavel Rappo Date: 2021-11-04 15:51:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf4ddf9cb7408db321e7fd73600a5a9a85ca49eb 8276338: Minor improve of wording for String.to(Lower|Upper)Case Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/lang/String.java Changeset: b57715a1 Author: Pavel Rappo Date: 2021-11-04 15:56:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b57715a117d9b7f79fcf4fec3b8f369b6aa42598 8276573: Use blessed modifier order in jdk.javadoc Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java Changeset: 7bb21733 Author: Brian Burkhalter Date: 2021-11-04 16:33:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7bb2173383bc1c0d55564d31303a547957d87a15 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly Reviewed-by: alanb ! test/jdk/ProblemList.txt ! test/jdk/java/nio/channels/FileChannel/LargeGatheringWrite.java Changeset: 1533b819 Author: Magnus Ihse Bursie Date: 2021-11-04 17:02:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1533b8191bed9d65ab4af03945584d8b2276d828 8276629: Use blessed modifier order in core-libs code Reviewed-by: dholmes, aefimov, dfuchs, mchung, iris ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/java.rmi/share/classes/java/rmi/server/LoaderHandler.java ! src/java.rmi/share/classes/java/rmi/server/RMISocketFactory.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObject.java ! src/java.rmi/share/classes/java/rmi/server/RemoteRef.java ! src/java.rmi/share/classes/java/rmi/server/RemoteStub.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java ! src/java.rmi/share/classes/sun/rmi/transport/ObjectTable.java ! src/java.rmi/share/classes/sun/rmi/transport/Target.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/jdk.dynalink/share/classes/jdk/dynalink/BiClassValue.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Annotation.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Dependencies.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ResourceFilter.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContext.java ! src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContextFactory.java Changeset: 99d4b07c Author: Ludvig Janiuk Committer: Mandy Chung Date: 2021-11-04 17:26:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99d4b07cddec05428e4d578ba6f494f51b92e841 8276649: MethodHandles.Lookup docs: replace the table in the cross-module access check section with list Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 2b5a32c7 Author: Zhengyu Gu Date: 2021-11-04 19:40:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b5a32c73f22c69d7ccedac761af1dbb4a7f297d 8275718: Relax memory constraint on exception counter updates Reviewed-by: dholmes, minqi ! src/hotspot/share/utilities/exceptions.cpp Changeset: 81203efe Author: Magnus Ihse Bursie Date: 2021-11-04 19:44:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81203efe411320ff4e390605f980d14e7f70252f 8276655: Use blessed modifier order in SCTP Reviewed-by: alanb, dfuchs ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/AssociationChange.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/PeerAddrChange.java Changeset: dcf36f87 Author: Dean Long Date: 2021-11-04 19:52:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dcf36f87f87d52490c1f0434c2fca99fc8fd90a2 8275670: ciReplay: java.lang.NoClassDefFoundError when trying to load java/lang/invoke/LambdaForm$MH Reviewed-by: kvn, chagedorn ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp + test/hotspot/jtreg/compiler/ciReplay/TestLambdas.java Changeset: 7e87f946 Author: Ludvig Janiuk Committer: Mandy Chung Date: 2021-11-04 20:46:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e87f946cedf93f19c38fd596039a16394c03ea4 8276652: Missing row headers in MethodHandles.Lookup docs Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 8ec80c4b Author: Ludvig Janiuk Committer: Naoto Sato Date: 2021-11-04 21:06:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8ec80c4bc1c3169963137b5a16a1b787540a3589 8276653: Missing row headers in j.l.Character docs Reviewed-by: naoto ! src/java.base/share/classes/java/lang/Character.java Changeset: 7b1916ef Author: Alisen Chung Committer: Phil Race Date: 2021-11-04 21:53:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b1916efda95a46439cf42e006593361d12a8823 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on macOs Reviewed-by: prr ! test/jdk/ProblemList.txt Changeset: e21b5c7b Author: Mandy Chung Date: 2021-11-04 23:51:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e21b5c7b3781430ecf568e7f5c89ef3391e06d9e 8276650: GenGraphs does not produce deterministic output Reviewed-by: iris ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java ! test/langtools/tools/jdeps/modules/DotFileTest.java Changeset: 9ad4d3d0 Author: Sandhya Viswanathan Date: 2021-11-05 03:30:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ad4d3d06bb356436d69af07726ef6727c500f59 8276025: Hotspot's libsvml.so may conflict with user dependency Reviewed-by: kvn, erikj, psandoz, ihse ! make/modules/jdk.incubator.vector/Lib.gmk ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp = src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_acos_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_asin_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cbrt_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_expm1_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log10_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log1p_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sinh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tanh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_acos_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_asin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cbrt_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cos_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_expm1_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log10_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log1p_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_pow_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sinh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tan_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tanh_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_acos_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_asin_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan2_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_cbrt_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_cosh_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_exp_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_expm1_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_log10_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_atan_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_cbrt_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_exp_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_expm1_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log10_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log1p_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log_linux_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cbrt_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_expm1_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_pow_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sinh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tanh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cbrt_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_expm1_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_pow_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sinh_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tanh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_acos_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_asin_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan2_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_cbrt_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_cosh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_exp_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_expm1_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_hypot_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log10_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log1p_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_pow_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_sinh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_tan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_tanh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_acos_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_asin_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan2_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_cbrt_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_cosh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_exp_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_expm1_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log10_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log1p_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_sinh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_tanh_windows_x86.S ! test/jdk/jdk/incubator/vector/ImageTest.java = test/jdk/jdk/incubator/vector/LoadJsvmlTest.java Changeset: 396132ff Author: Jaikiran Pai Date: 2021-11-05 03:44:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/396132ff1e56463ad195cac5c9ac8e2eac5a16e8 8275509: ModuleDescriptor.hashCode isn't reproducible across builds Reviewed-by: alanb, ihse ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java + test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java Changeset: 8e17ce00 Author: Ioi Lam Date: 2021-11-05 04:37:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8e17ce00316a765bbedefc34dc5898ba4f3f2144 8275185: Remove dead code and clean up jvmstat LocalVmManager Reviewed-by: cjplummer, redestad, kevinw ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java Changeset: 7281861e Author: Thomas Stuefe Date: 2021-11-05 05:15:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7281861e0662e6c51507066a1f12673a236c7491 8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 Reviewed-by: mchung, coleenp, dholmes ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp - src/hotspot/share/oops/reflectionAccessorImplKlassHelper.cpp - src/hotspot/share/oops/reflectionAccessorImplKlassHelper.hpp ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java - test/hotspot/jtreg/serviceability/dcmd/vm/ShowReflectionTargetTest.java Changeset: 96c396b7 Author: Ningsheng Jian Date: 2021-11-05 07:45:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96c396b701e290fc3e1124b1c862b41e02e9c1d9 8276151: AArch64: Incorrect result for double to int vector conversion Reviewed-by: aph, psandoz ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! test/hotspot/jtreg/compiler/vectorapi/VectorCastShape128Test.java ! test/hotspot/jtreg/compiler/vectorapi/VectorCastShape64Test.java Changeset: 323d2017 Author: Leo Korinth Date: 2021-11-05 09:25:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/323d2017959dc96d25eaa1aad6404586099c237e 8275506: Rename allocated_on_stack to allocated_on_stack_or_embedded Reviewed-by: stuefe ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/utilities/growableArray.cpp ! test/hotspot/gtest/utilities/test_growableArray.cpp Changeset: 3c0faa73 Author: Leo Korinth Date: 2021-11-05 09:42:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3c0faa73522bd004b66cb9e477f43e15a29842e6 8276173: Clean up and remove unneeded casts in HeapDumper Reviewed-by: coleenp, hseigel ! src/hotspot/share/services/heapDumper.cpp Changeset: d95299a4 Author: Patrick Concannon Date: 2021-11-05 10:39:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d95299a4d751449816ad2a88359f1e48e9608246 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java Reviewed-by: dfuchs, alanb, vtewari ! test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java ! test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java Changeset: a4e8d061 Author: duke Date: 2021-11-05 11:00:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a4e8d061d80cf9be501c9c700450891a445e7767 Automatic merge of jdk:master into master From jvernee at openjdk.java.net Fri Nov 5 14:17:20 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 5 Nov 2021 14:17:20 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 In-Reply-To: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> Message-ID: <6sXOIMe0ZcGTX-O0AZkYyJKI_jzW8z95CvDv8J2WBb8=.01c3664d-7d42-4cfc-b1c8-6c6bbd4f360f@github.com> On Fri, 5 Nov 2021 06:47:19 GMT, Nick Gasson wrote: > I removed the calls to change the W^X state in on_entry/on_exit calls: > in the on_entry case the stub must already be executable because we > called into the VM from there, and for on_exit we need the code to be > executable not writable otherwise we'll get a SIGBUS as soon as we > return to the stub. Thanks for cleaning this up as well. That code was taken from `JavaCallWrapper` code. Do you happen to know which use-case those calls were supposed to address? (I'm assuming things still work on MacOS/AArch64 without them). --- W.R.T. to JDK-8275584, I was wondering how JNI handles this, but it looks like it doesn't: #ifdef __APPLE__ // Less-than word types are stored one after another. // The code is unable to handle this so bailout. return -1; #endif (in SharedRuntime_aarch64). Maybe for now we should add a similar early bailout in Java code on MacOS/AArch64, until we have a chance to implement this. --- WRT to performance, I see somewhat comparable numbers (but on a different scale), on my x64 machine: Benchmark Mode Cnt Score Error Units Upcalls.jni_args10 avgt 30 148.993 ? 1.492 ns/op Upcalls.jni_args5 avgt 30 79.690 ? 0.753 ns/op Upcalls.jni_blank avgt 30 55.017 ? 1.067 ns/op Upcalls.jni_identity avgt 30 120.529 ? 1.265 ns/op Upcalls.panama_args10 avgt 30 55.065 ? 1.037 ns/op Upcalls.panama_args5 avgt 30 53.792 ? 2.640 ns/op Upcalls.panama_blank avgt 30 47.916 ? 1.764 ns/op Upcalls.panama_identity avgt 30 49.680 ? 1.604 ns/op --- > ForeignGlobals::parse_call_regs_impl() could be moved to shared code? Ok, feel free to move it to shared code if you want. src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 119: > 117: jint index = storage->int_field(VMS.index_offset); > 118: jint type = storage->int_field(VMS.type_offset); > 119: result._ret_regs[i] = vmstorage_to_vmreg(type, index); On x86, I switched these out to call `parse_vmstorage` which is a little simpler. src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 217: > 215: // skip receiver > 216: BasicType* in_sig_bt = out_sig_bt + 1; > 217: int total_in_args = total_out_args - 1; This section could also be moved to shared code as well (I did that in the pending patch as well: https://github.com/openjdk/panama-foreign/pull/608/files#r741389756 but it would be fine to do it here instead of you want) src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 395: > 393: blob->print_on(tty); > 394: Disassembler::decode(blob, tty); > 395: } I think I cleaned this up for x64 in the pending patch as well: `blob->print_on` already prints the disassembly, so the second call to `decode` is not needed (and you can remove the include for disassembler as well). src/hotspot/share/code/codeBlob.cpp line 253: > 251: > 252: BufferBlob::BufferBlob(const char* name, int header_size, int size, CodeBuffer* cb) > 253: : RuntimeBlob(name, cb, header_size, size, CodeOffsets::frame_never_safe, 0, NULL) Thanks for fixing this. Not sure why I never saw any problems on x64 (maybe some padding somewhere saved us). ------------- Marked as reviewed by jvernee (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/610 From ngasson at openjdk.java.net Mon Nov 8 09:13:43 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 8 Nov 2021 09:13:43 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 [v2] In-Reply-To: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> Message-ID: > This is a fairly direct port of the X86 code. The changes to > frame_aarch64 and foreign_globals_aarch64 are identical: perhaps > ForeignGlobals::parse_call_regs_impl() could be moved to shared code? > > The X86 version has a call to reinit_heapbase() before the return from > the stub. I think this is redundant because the heap base register will > be clobbered immediately by the native code? > > I hit a really weird bug in release builds where the first few > instructions in the code buffer were overwritten by the fields of > OptimizedEntryBlob. I think we need to pass sizeof(OptimizedEntryBlob) > instead of sizeof(BufferBlob) as the header_size argument to the > RuntimeBlob constructor (none of the other subclasses of BufferBlob have > extra fields). I added a header_size argument to BufferBlob's > constructor to thread this through. > > I removed the calls to change the W^X state in on_entry/on_exit calls: > in the on_entry case the stub must already be executable because we > called into the VM from there, and for on_exit we need the code to be > executable not writable otherwise we'll get a SIGBUS as soon as we > return to the stub. The newly added stack tests in TestUpcall hit > JDK-8275584 on MacOS/AArch64 so I've problem-listed that for now. > > JMH results from org.openjdk.bench.jdk.incubator.foreign.Upcalls before: > > > Benchmark Mode Cnt Score Error Units > Upcalls.jni_args10 avgt 30 450.417 ? 4.755 ns/op > Upcalls.jni_args5 avgt 30 245.898 ? 3.171 ns/op > Upcalls.jni_blank avgt 30 195.606 ? 5.459 ns/op > Upcalls.jni_identity avgt 30 369.788 ? 15.165 ns/op > Upcalls.panama_args10 avgt 30 1253.189 ? 62.261 ns/op > Upcalls.panama_args5 avgt 30 927.101 ? 35.369 ns/op > Upcalls.panama_blank avgt 30 637.708 ? 11.353 ns/op > Upcalls.panama_identity avgt 30 697.109 ? 9.971 ns/op > > > After: > > > Benchmark Mode Cnt Score Error Units > Upcalls.jni_args10 avgt 30 455.304 ? 21.838 ns/op > Upcalls.jni_args5 avgt 30 247.279 ? 2.513 ns/op > Upcalls.jni_blank avgt 30 194.113 ? 4.317 ns/op > Upcalls.jni_identity avgt 30 366.145 ? 4.912 ns/op > Upcalls.panama_args10 avgt 30 236.337 ? 11.072 ns/op > Upcalls.panama_args5 avgt 30 223.858 ? 12.345 ns/op > Upcalls.panama_blank avgt 30 203.631 ? 8.840 ns/op > Upcalls.panama_identity avgt 30 208.783 ? 9.914 ns/op > > > Tested tier1 and jdk_foreign on Linux/AArch64 and MacOS/AArch64. Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/610/files - new: https://git.openjdk.java.net/panama-foreign/pull/610/files/d385e964..e3fa6210 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=610&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=610&range=00-01 Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/610.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/610/head:pull/610 PR: https://git.openjdk.java.net/panama-foreign/pull/610 From ngasson at openjdk.java.net Mon Nov 8 09:23:04 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 8 Nov 2021 09:23:04 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 In-Reply-To: References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> Message-ID: On Fri, 5 Nov 2021 10:34:31 GMT, Andrew Haley wrote: > I'm interested to know where all that 250ns is going. Did you look at -prof perfasm? I should have tested on a more modern machine. Here's the results from an N1 server: Before: Benchmark Mode Cnt Score Error Units Upcalls.jni_args10 avgt 30 168.016 ? 0.571 ns/op Upcalls.jni_args5 avgt 30 98.907 ? 0.833 ns/op Upcalls.jni_blank avgt 30 78.007 ? 0.138 ns/op Upcalls.jni_identity avgt 30 150.933 ? 0.854 ns/op Upcalls.panama_args10 avgt 30 600.304 ? 35.944 ns/op Upcalls.panama_args5 avgt 30 447.607 ? 24.090 ns/op Upcalls.panama_blank avgt 30 238.953 ? 12.512 ns/op Upcalls.panama_identity avgt 30 314.388 ? 31.383 ns/op After: Benchmark Mode Cnt Score Error Units Upcalls.jni_args10 avgt 30 168.528 ? 0.658 ns/op Upcalls.jni_args5 avgt 30 98.595 ? 0.628 ns/op Upcalls.jni_blank avgt 30 78.420 ? 0.376 ns/op Upcalls.jni_identity avgt 30 154.403 ? 2.090 ns/op Upcalls.panama_args10 avgt 30 86.066 ? 4.202 ns/op Upcalls.panama_args5 avgt 30 78.094 ? 3.718 ns/op Upcalls.panama_blank avgt 30 68.683 ? 2.107 ns/op Upcalls.panama_identity avgt 30 76.841 ? 11.340 ns/op Which is closer to the x86 results. The top two functions are the `on_entry` and `on_exit` VM calls: 20.44% libjvm.so ProgrammableUpcallHandler::on_entry (228 bytes) 12.30% libjvm.so ProgrammableUpcallHandler::on_exit (88 bytes) 9.20% runtime stub StubRoutines::atomic entry points (148 bytes) 8.65% c2, level 4 org.openjdk.bench.jdk.incubator.foreign.jmh_generated.Upcalls_panama_args5_jmhTest::panama_args5_avgt_jmhStub, version 1386 (100 bytes) 4.64% libjvm.so ThreadShadow::clear_pending_exception (32 bytes) 4.07% c2, level 4 java.lang.invoke.LambdaForm$MH.0x0000000800d12c00::invoke, version 1369 (212 bytes) 3.94% c2, level 4 java.lang.invoke.LambdaForm$MH.0x0000000800d12c00::invoke, version 1369 (268 bytes) > That code was taken from JavaCallWrapper code. Do you happen to know which use-case those calls were supposed to address? (I'm assuming things still work on MacOS/AArch64 without them). I think the flow for JavaCallWrapper is slightly different. It's doing: Native -> JavaCallWrapper -> Java (need X) -> ~JavaCallWrapper -> Native (need W?) Whereas here we're doing: Native -> Stub (need X) -> on_entry -> Java (need X) -> on_exit -> Stub (need X) -> Native I'm not sure why ~JavaCallWrapper needs to set the W mode though. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/610 From ngasson at openjdk.java.net Mon Nov 8 09:23:11 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 8 Nov 2021 09:23:11 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 [v2] In-Reply-To: <6sXOIMe0ZcGTX-O0AZkYyJKI_jzW8z95CvDv8J2WBb8=.01c3664d-7d42-4cfc-b1c8-6c6bbd4f360f@github.com> References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> <6sXOIMe0ZcGTX-O0AZkYyJKI_jzW8z95CvDv8J2WBb8=.01c3664d-7d42-4cfc-b1c8-6c6bbd4f360f@github.com> Message-ID: On Fri, 5 Nov 2021 13:54:59 GMT, Jorn Vernee wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 217: > >> 215: // skip receiver >> 216: BasicType* in_sig_bt = out_sig_bt + 1; >> 217: int total_in_args = total_out_args - 1; > > This section could also be moved to shared code as well (I did that in the pending patch as well: https://github.com/openjdk/panama-foreign/pull/608/files#r741389756 but it would be fine to do it here instead of you want) I think I'll leave it as it is here to minimise changes - you'll need to rebase that patch anyway? I made the other two suggested clean-ups. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/610 From eliu at openjdk.java.net Mon Nov 8 10:16:10 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Mon, 8 Nov 2021 10:16:10 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v2] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Wed, 3 Nov 2021 07:55:57 GMT, Mai ??ng Qu?n Anh wrote: >> Hi, >> This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. >> Thank you very much. > > Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: > > - fix last true > - further improvement src/hotspot/share/opto/vectorIntrinsics.cpp line 703: > 701: if (mask_vec->bottom_type()->isa_vectmask() == NULL) { > 702: mask_vec = gvn().transform(VectorStoreMaskNode::make(gvn(), mask_vec, elem_bt, num_elem)); > 703: } There may have some regressions on AArch64 after refactoring those reduction operations base on this PR. With the `VectorStoreMaskNode`, the load-store pair could be optimized. After removing that, `VectorLoadMaskNode` needs extra extension instructions for various type. E.g. After: ldr h16, [x10, #16] // LoadVector uxtl v16.8h, v16.8b uxtl v16.4s, v16.4h uxtl v16.2d, v16.2s neg v16.2d, v16.2d // VectorLoadMask neg v17.2d, v16.2d addv b17, v17.16b umov w11, v17.b[0] // TrueCount sxtw x0, w11 // StoreVector Before: ldr h16, [x10, #16] // LoadVector addv b17, v16.8b umov w11, v17.b[0] // TrueCount sxtw x0, w11 // StoreVector No sliver bullet on this problem. Either you can match `VectorMaskTrueCount (VectorLoadMask src)` on AArch64 with this mid-end change in your patch, or just let the mid-end stay the same and match `VectorMaskTrueCount (VectorStoreMask src)` on x86 to pursue the better performance. The later would be better for its less effort. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From aph at openjdk.java.net Mon Nov 8 10:51:15 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 8 Nov 2021 10:51:15 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 [v2] In-Reply-To: References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> Message-ID: On Mon, 8 Nov 2021 09:13:43 GMT, Nick Gasson wrote: >> This is a fairly direct port of the X86 code. The changes to >> frame_aarch64 and foreign_globals_aarch64 are identical: perhaps >> ForeignGlobals::parse_call_regs_impl() could be moved to shared code? >> >> The X86 version has a call to reinit_heapbase() before the return from >> the stub. I think this is redundant because the heap base register will >> be clobbered immediately by the native code? >> >> I hit a really weird bug in release builds where the first few >> instructions in the code buffer were overwritten by the fields of >> OptimizedEntryBlob. I think we need to pass sizeof(OptimizedEntryBlob) >> instead of sizeof(BufferBlob) as the header_size argument to the >> RuntimeBlob constructor (none of the other subclasses of BufferBlob have >> extra fields). I added a header_size argument to BufferBlob's >> constructor to thread this through. >> >> I removed the calls to change the W^X state in on_entry/on_exit calls: >> in the on_entry case the stub must already be executable because we >> called into the VM from there, and for on_exit we need the code to be >> executable not writable otherwise we'll get a SIGBUS as soon as we >> return to the stub. The newly added stack tests in TestUpcall hit >> JDK-8275584 on MacOS/AArch64 so I've problem-listed that for now. >> >> JMH results from org.openjdk.bench.jdk.incubator.foreign.Upcalls before: >> >> >> Benchmark Mode Cnt Score Error Units >> Upcalls.jni_args10 avgt 30 450.417 ? 4.755 ns/op >> Upcalls.jni_args5 avgt 30 245.898 ? 3.171 ns/op >> Upcalls.jni_blank avgt 30 195.606 ? 5.459 ns/op >> Upcalls.jni_identity avgt 30 369.788 ? 15.165 ns/op >> Upcalls.panama_args10 avgt 30 1253.189 ? 62.261 ns/op >> Upcalls.panama_args5 avgt 30 927.101 ? 35.369 ns/op >> Upcalls.panama_blank avgt 30 637.708 ? 11.353 ns/op >> Upcalls.panama_identity avgt 30 697.109 ? 9.971 ns/op >> >> >> After: >> >> >> Benchmark Mode Cnt Score Error Units >> Upcalls.jni_args10 avgt 30 455.304 ? 21.838 ns/op >> Upcalls.jni_args5 avgt 30 247.279 ? 2.513 ns/op >> Upcalls.jni_blank avgt 30 194.113 ? 4.317 ns/op >> Upcalls.jni_identity avgt 30 366.145 ? 4.912 ns/op >> Upcalls.panama_args10 avgt 30 236.337 ? 11.072 ns/op >> Upcalls.panama_args5 avgt 30 223.858 ? 12.345 ns/op >> Upcalls.panama_blank avgt 30 203.631 ? 8.840 ns/op >> Upcalls.panama_identity avgt 30 208.783 ? 9.914 ns/op >> >> >> Tested tier1 and jdk_foreign on Linux/AArch64 and MacOS/AArch64. > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Tried on MacOS, this is _very_ weird: ....[Hottest Methods (after inlining)].............................................................. 25.52% runtime stub StubRoutines::updateBytesAdler32 19.98% c2, level 4 java.lang.invoke.LambdaForm$MH.0x00000008001b9000::invoke, version 1269 13.64% libjvm.dylib ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData*) 9.54% c2, level 4 java.lang.invoke.LambdaForm$MH.0x00000008001b8000::invoke, version 1260 5.74% libdyld.dylib tlv_get_addr 5.35% libjvm.dylib JNIHandleBlock::allocate_block(Thread*, AllocFailStrategy::AllocFailEnum) 4.50% c2, level 4 org.openjdk.bench.jdk.incubator.foreign.jmh_generated.Upcalls_panama_args10_jmhTest::panama_args10_avgt_jmhStub, version 1299 Adler32 is used by zlib, right? So something is repeatedly scanning compressed jarfiles, or something. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/610 From aph at openjdk.java.net Mon Nov 8 10:51:16 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 8 Nov 2021 10:51:16 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 [v2] In-Reply-To: <6sXOIMe0ZcGTX-O0AZkYyJKI_jzW8z95CvDv8J2WBb8=.01c3664d-7d42-4cfc-b1c8-6c6bbd4f360f@github.com> References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> <6sXOIMe0ZcGTX-O0AZkYyJKI_jzW8z95CvDv8J2WBb8=.01c3664d-7d42-4cfc-b1c8-6c6bbd4f360f@github.com> Message-ID: On Fri, 5 Nov 2021 14:14:24 GMT, Jorn Vernee wrote: > > I removed the calls to change the W^X state in on_entry/on_exit calls: > > in the on_entry case the stub must already be executable because we > > called into the VM from there, and for on_exit we need the code to be > > executable not writable otherwise we'll get a SIGBUS as soon as we > > return to the stub. > > Thanks for cleaning this up as well. That code was taken from `JavaCallWrapper` code. Do you happen to know which use-case those calls were supposed to address? (I'm assuming things still work on MacOS/AArch64 without them). This is in case native calls cause JIT patching. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/610 From jvernee at openjdk.java.net Mon Nov 8 12:44:42 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 8 Nov 2021 12:44:42 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 [v2] In-Reply-To: References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> <6sXOIMe0ZcGTX-O0AZkYyJKI_jzW8z95CvDv8J2WBb8=.01c3664d-7d42-4cfc-b1c8-6c6bbd4f360f@github.com> Message-ID: On Mon, 8 Nov 2021 09:10:13 GMT, Nick Gasson wrote: >> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 217: >> >>> 215: // skip receiver >>> 216: BasicType* in_sig_bt = out_sig_bt + 1; >>> 217: int total_in_args = total_out_args - 1; >> >> This section could also be moved to shared code as well (I did that in the pending patch as well: https://github.com/openjdk/panama-foreign/pull/608/files#r741389756 but it would be fine to do it here instead of you want) > > I think I'll leave it as it is here to minimise changes - you'll need to rebase that patch anyway? I made the other two suggested clean-ups. Sure, that's fine. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/610 From jvernee at openjdk.java.net Mon Nov 8 12:55:58 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 8 Nov 2021 12:55:58 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 [v2] In-Reply-To: References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> Message-ID: On Mon, 8 Nov 2021 09:13:43 GMT, Nick Gasson wrote: >> This is a fairly direct port of the X86 code. The changes to >> frame_aarch64 and foreign_globals_aarch64 are identical: perhaps >> ForeignGlobals::parse_call_regs_impl() could be moved to shared code? >> >> The X86 version has a call to reinit_heapbase() before the return from >> the stub. I think this is redundant because the heap base register will >> be clobbered immediately by the native code? >> >> I hit a really weird bug in release builds where the first few >> instructions in the code buffer were overwritten by the fields of >> OptimizedEntryBlob. I think we need to pass sizeof(OptimizedEntryBlob) >> instead of sizeof(BufferBlob) as the header_size argument to the >> RuntimeBlob constructor (none of the other subclasses of BufferBlob have >> extra fields). I added a header_size argument to BufferBlob's >> constructor to thread this through. >> >> I removed the calls to change the W^X state in on_entry/on_exit calls: >> in the on_entry case the stub must already be executable because we >> called into the VM from there, and for on_exit we need the code to be >> executable not writable otherwise we'll get a SIGBUS as soon as we >> return to the stub. The newly added stack tests in TestUpcall hit >> JDK-8275584 on MacOS/AArch64 so I've problem-listed that for now. >> >> JMH results from org.openjdk.bench.jdk.incubator.foreign.Upcalls before: >> >> >> Benchmark Mode Cnt Score Error Units >> Upcalls.jni_args10 avgt 30 450.417 ? 4.755 ns/op >> Upcalls.jni_args5 avgt 30 245.898 ? 3.171 ns/op >> Upcalls.jni_blank avgt 30 195.606 ? 5.459 ns/op >> Upcalls.jni_identity avgt 30 369.788 ? 15.165 ns/op >> Upcalls.panama_args10 avgt 30 1253.189 ? 62.261 ns/op >> Upcalls.panama_args5 avgt 30 927.101 ? 35.369 ns/op >> Upcalls.panama_blank avgt 30 637.708 ? 11.353 ns/op >> Upcalls.panama_identity avgt 30 697.109 ? 9.971 ns/op >> >> >> After: >> >> >> Benchmark Mode Cnt Score Error Units >> Upcalls.jni_args10 avgt 30 455.304 ? 21.838 ns/op >> Upcalls.jni_args5 avgt 30 247.279 ? 2.513 ns/op >> Upcalls.jni_blank avgt 30 194.113 ? 4.317 ns/op >> Upcalls.jni_identity avgt 30 366.145 ? 4.912 ns/op >> Upcalls.panama_args10 avgt 30 236.337 ? 11.072 ns/op >> Upcalls.panama_args5 avgt 30 223.858 ? 12.345 ns/op >> Upcalls.panama_blank avgt 30 203.631 ? 8.840 ns/op >> Upcalls.panama_identity avgt 30 208.783 ? 9.914 ns/op >> >> >> Tested tier1 and jdk_foreign on Linux/AArch64 and MacOS/AArch64. > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments LGTM. Feel free to integrate like this. ------------- Marked as reviewed by jvernee (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/610 From markehammons at gmail.com Mon Nov 8 23:08:42 2021 From: markehammons at gmail.com (markehammons at gmail.com) Date: Tue, 9 Nov 2021 00:08:42 +0100 Subject: Freeing memory from a segment allocator? Message-ID: Is there a way to free a memory segment and return its memory to the segment allocator that it was made from? Mark Edgar Hammons II 0603695656 From markehammons at gmail.com Mon Nov 8 23:21:52 2021 From: markehammons at gmail.com (markehammons at gmail.com) Date: Tue, 9 Nov 2021 00:21:52 +0100 Subject: =?utf-8?Q?SLinC:_scala_<->_C_interop_powered_by_panama=E2=80=99s?= =?utf-8?Q?_foreign_?= Message-ID: Hi all, I wanted to share with you a library I?m writing for Scala 3 called SLinC (Scala Link to C). https://gitlab.com/mhammons/slinc I?d like to thank the Panama team for their hard work. I was able to write this library and immediately see good performance out of it thanks to you. I?m hoping to refine and upgrade the library over this coming month, and I hope you all won?t mind if I ask for a bit of help or make suggestions now and then. Mark Edgar Hammons II From jbhateja at openjdk.java.net Tue Nov 9 05:56:22 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 9 Nov 2021 05:56:22 GMT Subject: [vectorIntrinsics+compress] RFR: Merge panama-vector:vectorIntrinsics Message-ID: Merge latest code from vectorIntrinsics into vectorIntrinsics+compress branch Thanks, Jatin ------------- Commit messages: - Merge branch 'vectorIntrinsics' of http://github.com/openjdk/panama-vector into merge_vectorIntrinsics - Update perf tests. The webrevs contain the adjustments done while merging with regards to each parent branch: - vectorIntrinsics+compress: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=161&range=00.0 - panama-vector:vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=161&range=00.1 Changes: https://git.openjdk.java.net/panama-vector/pull/161/files Stats: 6674 lines in 39 files changed: 3836 ins; 2838 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/161.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/161/head:pull/161 PR: https://git.openjdk.java.net/panama-vector/pull/161 From eliu at openjdk.java.net Tue Nov 9 07:13:05 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Tue, 9 Nov 2021 07:13:05 GMT Subject: [vectorIntrinsics+compress] RFR: Merge panama-vector:vectorIntrinsics In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 05:51:13 GMT, Jatin Bhateja wrote: > Merge latest code from vectorIntrinsics into vectorIntrinsics+compress branch > > Thanks, > Jatin Marked as reviewed by eliu (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/161 From ngasson at openjdk.java.net Tue Nov 9 09:04:48 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 9 Nov 2021 09:04:48 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 [v2] In-Reply-To: References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> Message-ID: On Mon, 8 Nov 2021 10:46:08 GMT, Andrew Haley wrote: > Tried on MacOS, this is _very_ weird: > > ``` > ....[Hottest Methods (after inlining)].............................................................. > 25.52% runtime stub StubRoutines::updateBytesAdler32 >``` I think it's a bug in JMH's parsing of the `-XX:+PrintStubCode` output: it's expecting these to all be prefixed with `StubRoutines::` but many aren't including the `optimized_upcall_stub` added by this patch. `StubRoutines::updateBytesAdler32` is the last one printed with that prefix on MacOS, and likewise `StubRoutines::atomic entry points` is the last one printed on Linux (allegedly the third hottest method above). So I think it's been misattributed. I'll see if I can fix it... ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/610 From duke at openjdk.java.net Tue Nov 9 09:06:49 2021 From: duke at openjdk.java.net (duke) Date: Tue, 9 Nov 2021 09:06:49 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <407c53f3-0ace-4d67-a4ec-88c98710fa62@openjdk.org> Changeset: 9e9ba2e9 Author: Nick Gasson Date: 2021-11-09 09:04:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9e9ba2e99d3218f37b89e9cd0dae431f471be487 8275646: Implement optimized upcall stubs on AArch64 Reviewed-by: jvernee ! src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/prims/universalUpcallHandler.cpp ! src/hotspot/share/prims/whitebox.cpp ! test/jdk/ProblemList.txt Changeset: 9052a6a4 Author: duke Date: 2021-11-09 09:05:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9052a6a470eba7dfe449419c442e9af9c40793d7 Automatic merge of foreign-memaccess+abi into foreign-jextract From ngasson at openjdk.java.net Tue Nov 9 09:08:03 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 9 Nov 2021 09:08:03 GMT Subject: [foreign-memaccess+abi] Integrated: 8275646: Implement optimized upcall stubs on AArch64 In-Reply-To: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> Message-ID: On Fri, 5 Nov 2021 06:47:19 GMT, Nick Gasson wrote: > This is a fairly direct port of the X86 code. The changes to > frame_aarch64 and foreign_globals_aarch64 are identical: perhaps > ForeignGlobals::parse_call_regs_impl() could be moved to shared code? > > The X86 version has a call to reinit_heapbase() before the return from > the stub. I think this is redundant because the heap base register will > be clobbered immediately by the native code? > > I hit a really weird bug in release builds where the first few > instructions in the code buffer were overwritten by the fields of > OptimizedEntryBlob. I think we need to pass sizeof(OptimizedEntryBlob) > instead of sizeof(BufferBlob) as the header_size argument to the > RuntimeBlob constructor (none of the other subclasses of BufferBlob have > extra fields). I added a header_size argument to BufferBlob's > constructor to thread this through. > > I removed the calls to change the W^X state in on_entry/on_exit calls: > in the on_entry case the stub must already be executable because we > called into the VM from there, and for on_exit we need the code to be > executable not writable otherwise we'll get a SIGBUS as soon as we > return to the stub. The newly added stack tests in TestUpcall hit > JDK-8275584 on MacOS/AArch64 so I've problem-listed that for now. > > JMH results from org.openjdk.bench.jdk.incubator.foreign.Upcalls before: > > > Benchmark Mode Cnt Score Error Units > Upcalls.jni_args10 avgt 30 450.417 ? 4.755 ns/op > Upcalls.jni_args5 avgt 30 245.898 ? 3.171 ns/op > Upcalls.jni_blank avgt 30 195.606 ? 5.459 ns/op > Upcalls.jni_identity avgt 30 369.788 ? 15.165 ns/op > Upcalls.panama_args10 avgt 30 1253.189 ? 62.261 ns/op > Upcalls.panama_args5 avgt 30 927.101 ? 35.369 ns/op > Upcalls.panama_blank avgt 30 637.708 ? 11.353 ns/op > Upcalls.panama_identity avgt 30 697.109 ? 9.971 ns/op > > > After: > > > Benchmark Mode Cnt Score Error Units > Upcalls.jni_args10 avgt 30 455.304 ? 21.838 ns/op > Upcalls.jni_args5 avgt 30 247.279 ? 2.513 ns/op > Upcalls.jni_blank avgt 30 194.113 ? 4.317 ns/op > Upcalls.jni_identity avgt 30 366.145 ? 4.912 ns/op > Upcalls.panama_args10 avgt 30 236.337 ? 11.072 ns/op > Upcalls.panama_args5 avgt 30 223.858 ? 12.345 ns/op > Upcalls.panama_blank avgt 30 203.631 ? 8.840 ns/op > Upcalls.panama_identity avgt 30 208.783 ? 9.914 ns/op > > > Tested tier1 and jdk_foreign on Linux/AArch64 and MacOS/AArch64. This pull request has now been integrated. Changeset: 9e9ba2e9 Author: Nick Gasson URL: https://git.openjdk.java.net/panama-foreign/commit/9e9ba2e99d3218f37b89e9cd0dae431f471be487 Stats: 370 lines in 9 files changed: 336 ins; 4 del; 30 mod 8275646: Implement optimized upcall stubs on AArch64 Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/610 From aph at openjdk.java.net Tue Nov 9 09:49:00 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 9 Nov 2021 09:49:00 GMT Subject: [foreign-memaccess+abi] RFR: 8275646: Implement optimized upcall stubs on AArch64 [v2] In-Reply-To: References: <5-jW5Kcv3h2WySXJ5Ny9fCruJjrYPaaPui6Ya1LM76g=.dc9d86c8-4a27-40ed-b6b1-fbedb63545c1@github.com> Message-ID: On Tue, 9 Nov 2021 09:02:02 GMT, Nick Gasson wrote: > > Tried on MacOS, this is _very_ weird: > > ``` > > ....[Hottest Methods (after inlining)].............................................................. > > 25.52% runtime stub StubRoutines::updateBytesAdler32 > > ``` > > I think it's a bug in JMH's parsing of the `-XX:+PrintStubCode` output: it's expecting these to all be prefixed with `StubRoutines::` but many aren't including the `optimized_upcall_stub` added by this patch. `StubRoutines::updateBytesAdler32` is the last one printed with that prefix on MacOS, and likewise `StubRoutines::atomic entry points` is the last one printed on Linux (allegedly the third hottest method above). So I think it's been misattributed. I'll see if I can fix it... That makes perfect sense. I'm making rather a fuss about this because I think I know how long a direct call _should_ make_, and indeed does make in C++. It could be that this really is the best we can do. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/610 From maurizio.cimadamore at oracle.com Tue Nov 9 11:04:46 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Nov 2021 11:04:46 +0000 Subject: Freeing memory from a segment allocator? In-Reply-To: References: Message-ID: Hi Mark, A segment allocator is just a plain functional interface - what happens when you do "allocate" is up to the allocator implementation. The few allocators provided by the Panama API do not provide the capability you describe - that said, some developers have successfully been able to use the Panama API to build allocators which act as memory pool, such as this fine example: https://github.com/openjdk/panama-foreign/pull/509 The workflow with these allocators is like this: 1. You create a memory pool and you store it in some field 2. A client creates a resource scope 3. The scope is used to obtain a "pooled allocator" from the pool 4. The client alocates memory with the pooled allocator 5. When the client scope is closed, all the memory allocated with pooled allocator is released back to the pool In other words, combining resource scopes (which give you a lifecycle capability) with a segment allocator (which give you an allocation capability) it is possible to define allocators which "recycle" memory across multiple clients. We might, at some point, provide a ready-made memory pool of this sort in the API - but right now we're focusing on getting the basics right ;-) Cheers Maurizio On 08/11/2021 23:08, markehammons at gmail.com wrote: > Is there a way to free a memory segment and return its memory to the segment allocator that it was made from? > > Mark Edgar Hammons II > 0603695656 From maurizio.cimadamore at oracle.com Tue Nov 9 11:21:14 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Nov 2021 11:21:14 +0000 Subject: =?UTF-8?Q?Re=3a_SLinC=3a_scala_=3c-=3e_C_interop_powered_by_panama?= =?UTF-8?B?4oCZcyBmb3JlaWdu?= In-Reply-To: References: Message-ID: <28225700-1b2c-1868-968a-905c9602a103@oracle.com> Hi Mark, thanks for sharing this. I think this is a very cool example of building an interop layer (in a different language!) on top of the C linker API. I like the way you used some of the "static" Scala features (such as macros) to make linking more succint (but w/o losing anything performance-wise). Regarding structs, I believe at some point you might need some way to allow clients to specify custom layouts (e.g. in the presence of padding) - that's where things become a bit hairy for structs. In other words, the types of the declared fields (two Ints in this case) are not enough to fully specify the layout of the div_t struct. Perhaps this is something that can be fixed by adding some parameterization: ``` Struct[ div_tLayout ] { ?? ... } div_t ``` (Similarly to what you have done for linking functions). And, if you use some compact string representation for the layout, perhaps that's just a string: ``` Struct[ "[ b32(quot) b32(rem) ]" ] { ??? val quot: int ??? val rem: int } div_t ``` But these are details, which I'm sure will be ironed out. Cheers Maurizio On 08/11/2021 23:21, markehammons at gmail.com wrote: > Hi all, I wanted to share with you a library I?m writing for Scala 3 called SLinC (Scala Link to C). > > https://gitlab.com/mhammons/slinc > > I?d like to thank the Panama team for their hard work. I was able to write this library and immediately see good performance out of it thanks to you. I?m hoping to refine and upgrade the library over this coming month, and I hope you all won?t mind if I ask for a bit of help or make suggestions now and then. > > Mark Edgar Hammons II From jbhateja at openjdk.java.net Tue Nov 9 12:18:56 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 9 Nov 2021 12:18:56 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v2] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Wed, 3 Nov 2021 07:55:57 GMT, Mai ??ng Qu?n Anh wrote: >> Hi, >> This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. >> Thank you very much. > > Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: > > - fix last true > - further improvement Over all changes looks ok to me. - Savings are majorly because we are preventing additional vector store mask. - Tier-3/4 testing at various AVX Levels 0/1/2/3/KNL went clean. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4134: > 4132: lzcntl(dst, dst); > 4133: negl(dst); > 4134: addl(dst, 31); I think from latency perspective earlier sequence was better given that constant move to a register is not scheduled to an execution port. src/hotspot/cpu/x86/x86.ad line 8682: > 8680: __ vpmovmskb($dst$$Register, $xtmp$$XMMRegister, vlen_enc); > 8681: // Mask generated out of partial vector comparisons/replicate/mask manipulation > 8682: // operations needs to be clipped. Please keep this comment intact. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From jbhateja at openjdk.java.net Tue Nov 9 12:18:56 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 9 Nov 2021 12:18:56 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Tue, 2 Nov 2021 16:36:47 GMT, Paul Sandoz wrote: > > Besides, I found out that C2 fails with `Long128Vector`, even a simple operation of `LONG_128_1.eq(LONG_128_2)`, is this a known behaviour? > > I was not aware of that, @jatin-bhateja might know more. Yes, this the current [behavior ](https://github.com/openjdk/panama-vector/pull/157#discussion_r738549758) ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Tue Nov 9 16:14:26 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Tue, 9 Nov 2021 16:14:26 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v3] In-Reply-To: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: > Hi, > This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. > Thank you very much. Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: - support for non-bmi, some refinement - restore VectorStoreMaskNode, move logic to backend ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/158/files - new: https://git.openjdk.java.net/panama-vector/pull/158/files/4d0e7936..d3249aee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=158&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=158&range=01-02 Stats: 142 lines in 6 files changed: 93 ins; 16 del; 33 mod Patch: https://git.openjdk.java.net/panama-vector/pull/158.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/158/head:pull/158 PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Tue Nov 9 16:22:59 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Tue, 9 Nov 2021 16:22:59 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v3] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Mon, 8 Nov 2021 10:10:54 GMT, Eric Liu wrote: >> Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: >> >> - support for non-bmi, some refinement >> - restore VectorStoreMaskNode, move logic to backend > > src/hotspot/share/opto/vectorIntrinsics.cpp line 703: > >> 701: const Type* maskoper_ty = mopc == Op_VectorMaskToLong ? (const Type*)TypeLong::LONG : (const Type*)TypeInt::INT; >> 702: Node* maskoper = gvn().transform(VectorMaskOpNode::make(mask_vec, maskoper_ty, mopc)); >> 703: if (mopc != Op_VectorMaskToLong) { > > There may have some regressions on AArch64 after refactoring those reduction operations base on this PR. > > With the `VectorStoreMaskNode`, the load-store pair could be optimized. After removing that, `VectorLoadMaskNode` needs extra extension instructions for various type. E.g. > > > After: > ldr h16, [x10, #16] // LoadVector > uxtl v16.8h, v16.8b > uxtl v16.4s, v16.4h > uxtl v16.2d, v16.2s > neg v16.2d, v16.2d // VectorLoadMask > neg v17.2d, v16.2d > addv b17, v17.16b > umov w11, v17.b[0] // TrueCount > > Before: > > ldr h16, [x10, #16] // LoadVector > addv b17, v16.8b > umov w11, v17.b[0] // TrueCount > > > No sliver bullet on this problem. Either you can match `VectorMaskTrueCount (VectorLoadMask src)` on AArch64 with this mid-end change in your patch, or just let the mid-end stay the same and match `VectorMaskTrueCount (VectorStoreMask src)` on x86 to pursue the better performance. The later would be better for its less effort. Thank you very much for your investigation, I have reverted the changes in the mid-end and pushed the change to the back-end as your suggestion. Another approach may be to elide the `VectorLoadMaskNode` attached to a mask reduction node but I think it should be another PR later. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Tue Nov 9 16:28:52 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Tue, 9 Nov 2021 16:28:52 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v2] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Tue, 9 Nov 2021 12:03:03 GMT, Jatin Bhateja wrote: >> Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix last true >> - further improvement > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4134: > >> 4132: lzcntl(dst, dst); >> 4133: negl(dst); >> 4134: addl(dst, 31); > > I think from latency perspective earlier sequence was better given that constant move to a register is not scheduled to an execution port. I have reverted that change with a minor change from 64-bit operations to 32-bit operations. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Tue Nov 9 16:28:54 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Tue, 9 Nov 2021 16:28:54 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v3] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Tue, 9 Nov 2021 11:36:23 GMT, Jatin Bhateja wrote: >> Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: >> >> - support for non-bmi, some refinement >> - restore VectorStoreMaskNode, move logic to backend > > src/hotspot/cpu/x86/x86.ad line 8682: > >> 8680: __ vpmovmskb($dst$$Register, $xtmp$$XMMRegister, vlen_enc); >> 8681: // Mask generated out of partial vector comparisons/replicate/mask manipulation >> 8682: // operations needs to be clipped. > > Please keep this comment intact. Thank you very much for the review, I put the comment in C2_MacroAssembler where the clip occurs. Is it okay for you? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Tue Nov 9 16:33:46 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Tue, 9 Nov 2021 16:33:46 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v3] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Tue, 9 Nov 2021 16:14:26 GMT, Mai ??ng Qu?n Anh wrote: >> Hi, >> This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. >> Thank you very much. > > Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: > > - support for non-bmi, some refinement > - restore VectorStoreMaskNode, move logic to backend The latest change reverts the change in the mid-end and lets the x86 back-end perform the elision when matching. Some minor changes in the C2_MacroAssembler were made to improve the code emitted by first true operations, as well as to reduce the width of instructions that operate on index calculations from 64 bits to 32 bits. Thank you very much. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From jvernee at openjdk.java.net Tue Nov 9 16:43:19 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 9 Nov 2021 16:43:19 GMT Subject: [foreign-memaccess+abi] RFR: 8275647: Enable multi-register return values for optimized upcall stubs Message-ID: Hi, After we've added multi-register return support to native invokers, this patch does the same for optimized upcall stubs. The strategy is very similar: the caller (in this case the upcall stub) allocates a return buffer in which the return values are stored, and then after the upcall shuffles the return values from the buffer into the right registers. This patch also removes the buffered invocation strategy for upcalls, and all related code, such as BufferLayout. ~Note, in it's current state this patch will disable regress AArch64 since optimized upcalls are not implemented there yet. i.e. this PR is blocked by: https://bugs.openjdk.java.net/browse/JDK-8275646~ Jorn ------------- Commit messages: - fix receiver name - - AArch64 first impl - Cast to OptimizedEntryBlob after null check - Rename 'imr' + RB fixes - Remove some left-over buffered invocation code. - Clean up free upcall stubs - Remove the buffered invocation strategy - Implement upcall IMR specialization - Implement multi-register returns for upcalls (on x86_64) - interpreted only Changes: https://git.openjdk.java.net/panama-foreign/pull/608/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=608&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275647 Stats: 1167 lines in 32 files changed: 268 ins; 808 del; 91 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/608.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/608/head:pull/608 PR: https://git.openjdk.java.net/panama-foreign/pull/608 From ngasson at openjdk.java.net Tue Nov 9 16:43:20 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 9 Nov 2021 16:43:20 GMT Subject: [foreign-memaccess+abi] RFR: 8275647: Enable multi-register return values for optimized upcall stubs In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 19:07:45 GMT, Jorn Vernee wrote: > > Note, in it's current state this patch will disable regress AArch64 since optimized upcalls are not implemented there yet. i.e. this PR is blocked by: https://bugs.openjdk.java.net/browse/JDK-8275646 > I've nearly finished this, I'll send the patch tomorrow. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/608 From jvernee at openjdk.java.net Tue Nov 9 16:43:24 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 9 Nov 2021 16:43:24 GMT Subject: [foreign-memaccess+abi] RFR: 8275647: Enable multi-register return values for optimized upcall stubs In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 19:07:45 GMT, Jorn Vernee wrote: > Hi, > > After we've added multi-register return support to native invokers, this patch does the same for optimized upcall stubs. The strategy is very similar: the caller (in this case the upcall stub) allocates a return buffer in which the return values are stored, and then after the upcall shuffles the return values from the buffer into the right registers. > > This patch also removes the buffered invocation strategy for upcalls, and all related code, such as BufferLayout. > > ~Note, in it's current state this patch will disable regress AArch64 since optimized upcalls are not implemented there yet. i.e. this PR is blocked by: https://bugs.openjdk.java.net/browse/JDK-8275646~ > > Jorn src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 314: > 312: // skip receiver > 313: BasicType* in_sig_bt = out_sig_bt + 1; > 314: int total_in_args = total_out_args - 1; I've moved this to the shared code in universalUpcallHanlder.cpp, since it can be shared between platforms. src/hotspot/share/code/codeBlob.cpp line 759: > 757: JNIHandles::destroy_global(blob->receiver()); > 758: BufferBlob::free(blob); > 759: } We were freeing upcall stubs using CodeCache::free, but this doesn't track memory usage. I've added this method to properly handle freeing upcall stubs. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java line 143: > 141: > 142: // we handle returns first since IMR adds an extra parameter that needs to be specialized as well > 143: if (llReturn != void.class || callingSequence.needsReturnBuffer()) { Note that the old code for handling return values is just moved from below the code that handles arguments (and then handling for mutli-reg returns added to that), since the return buffer argument also needs to be handle along with the rest of arguments. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java line 203: > 201: CallingSequence callingSequence, > 202: Binding.VMStore[] retMoves, > 203: ABIDescriptor abi) {} Same as with downcalls, I've bundled all the extra arguments into a record. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/608 From jvernee at openjdk.java.net Tue Nov 9 20:00:56 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 9 Nov 2021 20:00:56 GMT Subject: [foreign-memaccess+abi] RFR: 8275647: Enable multi-register return values for optimized upcall stubs In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 19:07:45 GMT, Jorn Vernee wrote: > Hi, > > After we've added multi-register return support to native invokers, this patch does the same for optimized upcall stubs. The strategy is very similar: the caller (in this case the upcall stub) allocates a return buffer in which the return values are stored, and then after the upcall shuffles the return values from the buffer into the right registers. > > This patch also removes the buffered invocation strategy for upcalls, and all related code, such as BufferLayout. > > ~Note, in it's current state this patch will disable regress AArch64 since optimized upcalls are not implemented there yet. i.e. this PR is blocked by: https://bugs.openjdk.java.net/browse/JDK-8275646~ > > Jorn src/hotspot/cpu/x86/foreign_globals_x86.cpp line 96: > 94: } > 95: > 96: const CallRegs ForeignGlobals::parse_call_regs_impl(jobject jconv) const { This is now also moved to shared code. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/608 From remm at apache.org Wed Nov 10 09:20:42 2021 From: remm at apache.org (=?UTF-8?Q?R=C3=A9my_Maucherat?=) Date: Wed, 10 Nov 2021 10:20:42 +0100 Subject: OpenSSL and panama-foreign Message-ID: Hi, Apache Tomcat currently uses a JNI wrapper, called tomcat-native, to be able to use OpenSSL. It has been a long term goal to replace that JNI wrapper with "something else", as maintenance is annoying, support and debugging is annoying, adding new features is annoying, etc etc. After a failed attempt three years ago with Panama, the recent JEP 412 in Java 17 made it seem things were getting more mature and it looked feature complete enough for our use case. The good news is I was able to produce a functional equivalent of the OpenSSL JNI based code using the new APIs: Original: https://github.com/apache/tomcat/tree/10.1.0-M7/java/org/apache/tomcat/util/net/openssl and portions of https://github.com/apache/tomcat-native/tree/1.2.31/native Java 17: https://github.com/apache/tomcat/tree/10.1.0-M7/modules/openssl-java17 panama-foreign: https://github.com/rmaucher/openssl-panama-foreign Overall, this is very good, the needed functionality is there and the performance seems equivalent to JNI. However, I am running into cores (apparently caused by memory corruption) with the panama-foreign branch, while the Java 17 version seems solid. Example of a core: https://pastebin.com/Acq4tFgR Basically, some memory corruption causes crashes on some cleanup or other operations. It only happens under load with concurrency (I use something like "ab -n 10000 -c 10 https://127.0.0.1:8443/tomcat.svg" to generate a burst of parallel handshaking activity). The Java 17 version passes the same test. Things work fine if there's no significant load or if all operations are serialized using sync. I am using shared scopes for the SSL context and SSL engine. Each engine has its own scope, so allocated memory would be released once done with the associated connection. Any ideas of what could explain the problems with panama-foreign ? Thanks, R?my From maurizio.cimadamore at oracle.com Wed Nov 10 09:34:23 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Nov 2021 09:34:23 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: Message-ID: Hi, thanks for sharing the feedback! I'm glad you got something working. Hopefully we can fix the rest :-) On 10/11/2021 09:20, R?my Maucherat wrote: > However, I am running into cores (apparently caused by memory > corruption) with the panama-foreign branch, while the Java 17 version > seems solid. That is interesting information. So, you say that the Java 17 version works fine, but when building (latest) panama-foreign, you get some VM crash. Now, looking at the crash, it seems like it occurs in the middle of a native call: ``` Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v? ~RuntimeStub::nep_invoker_blob <------------ J 5738 c1 org.apache.tomcat.util.openssl.openssl_h.SSL_shutdown(Ljdk/incubator/foreign/Addressable;)I (31 bytes) @ 0x00007faf82340d2c [0x00007faf8233cc20+0x000000000000410c] J 5482 c1 org.apache.tomcat.util.net.openssl.panama.OpenSSLEngine.closeOutbound()V (76 bytes) @ 0x00007faf81a934e4 [0x00007faf81a93280+0x0000000000000264] ``` This area changed quite a bit recently, as we are refactoring and consolidating the linking functionalities to make it simpler for developers to port the CLInker implementation to other platforms. I wonder if a regression sneaked in (possible, the refactoring were quite big). In terms of support for shared scopes, the one thing that has changed from 16 to 17 is that now if you pass arguments by reference to functions, those references' scopes are "acquired" on function enter and "released" on function exit - which means it is not possible, even in a shared context, for e.g. the target address of a native function to be unloaded in the middle of a native call. But this should add _more_ safety, not less. I suppose that you tested Java 17 by using the jextract available in the Panama EA binaries; and that you tested the bits in panama-foreign by manually building them, and using the jextract you obtained as a result (e.g. using the EA jextract against the latest panama-foreign API will NOT work). Thanks Maurizio From remm at apache.org Wed Nov 10 11:20:36 2021 From: remm at apache.org (=?UTF-8?Q?R=C3=A9my_Maucherat?=) Date: Wed, 10 Nov 2021 12:20:36 +0100 Subject: OpenSSL and panama-foreign In-Reply-To: References: Message-ID: On Wed, Nov 10, 2021 at 10:34 AM Maurizio Cimadamore wrote: > > Hi, > thanks for sharing the feedback! I'm glad you got something working. > Hopefully we can fix the rest :-) > > On 10/11/2021 09:20, R?my Maucherat wrote: > > However, I am running into cores (apparently caused by memory > > corruption) with the panama-foreign branch, while the Java 17 version > > seems solid. > > That is interesting information. So, you say that the Java 17 version > works fine, but when building (latest) panama-foreign, you get some VM > crash. That's correct. I am not ready to call Java 17 totally stable yet, but it makes it through a reasonable amount of testing [h2, Tomcat testsuite, ab] and checks for memory leaks. This is getting released now so maybe this will get further testing. Only a heavy memory alloc/free activity seems to cause the cores, for example ab -k (which will do keepalive over existing connections and TLS engines) is almost stable. Without the -k, crashes always occur after only a few seconds of ab. Since this round of Tomcat releases is now done, I will see if I can produce a real test case for the problem. > Now, looking at the crash, it seems like it occurs in the middle of a > native call: > > ``` > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > v ~RuntimeStub::nep_invoker_blob <------------ > J 5738 c1 > org.apache.tomcat.util.openssl.openssl_h.SSL_shutdown(Ljdk/incubator/foreign/Addressable;)I > (31 bytes) @ 0x00007faf82340d2c [0x00007faf8233cc20+0x000000000000410c] > J 5482 c1 > org.apache.tomcat.util.net.openssl.panama.OpenSSLEngine.closeOutbound()V > (76 bytes) @ 0x00007faf81a934e4 [0x00007faf81a93280+0x0000000000000264] > ``` > > This area changed quite a bit recently, as we are refactoring and > consolidating the linking functionalities to make it simpler for > developers to port the CLInker implementation to other platforms. I > wonder if a regression sneaked in (possible, the refactoring were quite > big). Crashes happen in multiple locations (internal JVM, SSL_read, SSL_shutdown), but the easiest to investigate was the SSL_shutdown one. In gdb, the debug is: #10 ssl3_shutdown (s=0x0) at ssl/s3_lib.c:4420 4420 if (s->s3->alert_dispatch) (gdb) print s $1 = (SSL *) 0x0 With the corresponding source: 4400 int ssl3_shutdown(SSL *s) 4401 { 4402 int ret; 4403 4404 /* 4405 * Don't do anything much if we have not done the handshake or we don't 4406 * want to send messages :-) 4407 */ 4408 if (s->quiet_shutdown || SSL_in_before(s)) { 4409 s->shutdown = (SSL_SENT_SHUTDOWN | SSL_RECEIVED_SHUTDOWN); 4410 return 1; 4411 } 4412 4413 if (!(s->shutdown & SSL_SENT_SHUTDOWN)) { 4414 s->shutdown |= SSL_SENT_SHUTDOWN; 4415 ssl3_send_alert(s, SSL3_AL_WARNING, SSL_AD_CLOSE_NOTIFY); 4416 /* 4417 * our shutdown alert has been sent now, and if it still needs to be 4418 * written, s->s3->alert_dispatch will be true 4419 */ 4420 if (s->s3->alert_dispatch) 4421 return -1; /* return WANT_WRITE */ 4422 } else if (s->s3->alert_dispatch) { 4423 /* resend it if not sent */ 4424 ret = s->method->ssl_dispatch_alert(s); 4425 if (ret == -1) { 4426 /* 4427 * we only get to return -1 here the 2nd/Nth invocation, we must 4428 * have already signalled return 0 upon a previous invocation, 4429 * return WANT_WRITE 4430 */ 4431 return ret; 4432 } OpenSSL does its own malloc/free for most of its structures, for example the SSL is allocated with SSL_new and freed with SSL_free. There are hooks to provide your own malloc/free for integration and leak debugging. I actually tried panama-izing these to see what would happen, but this only caused cores (after a few hundred successful allocations, the main init OPENSSL_init_ssl would cause a crash). > In terms of support for shared scopes, the one thing that has changed > from 16 to 17 is that now if you pass arguments by reference to > functions, those references' scopes are "acquired" on function enter and > "released" on function exit - which means it is not possible, even in a > shared context, for e.g. the target address of a native function to be > unloaded in the middle of a native call. But this should add _more_ > safety, not less. Ok, that sounds like a good strategy. > I suppose that you tested Java 17 by using the jextract available in the > Panama EA binaries; and that you tested the bits in panama-foreign by > manually building them, and using the jextract you obtained as a result > (e.g. using the EA jextract against the latest panama-foreign API will > NOT work). Yes, for panama-foreign I am using the current commit with a jextract built from there. For Java 17, it took me a couple hours to figure out the pre built jextract binary at http://jdk.java.net/panama/ was the best option. The original plan for this OpenSSL module was to support panama-foreign and track the API changes (plus bugfixes and improvements). I expected Java 17 would need fixes [which would then only be available in the dev branch]. Thanks for the quick response ! R?my > Thanks > Maurizio > From maurizio.cimadamore at oracle.com Wed Nov 10 12:53:17 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Nov 2021 12:53:17 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: Message-ID: <38c1be7a-dedb-6576-cdac-ea51b230dcb8@oracle.com> Looking more at your code, I noticed you use cleaners: https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L275 That is, when the engine is unreacheable, you have some cleanup actions: https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L1868 Note that you can probably achieve the same effect by registering the scope with a cleaner, and then add a "close action" on the cleaner itself, to close the scope. But this is an optional suggestion. What I find more disturbing is that the addresses you generate, e.g. this: https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/openssl/openssl_h.java#L1327 This `ssl` address is just a raw memory address - it doesn't have any real temporal bounds. It is not attached to the scope you create in any way. So, when you do this: https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L766 The linker won't really protect that call in any way. There's no way for the linker to know whether the address is still available or not. Which might be ok if the memory is managed by SSL anyway. But the issue here, as your debugging session shows, is that, somehow, you end up calling SSL_shutdown on a bad SSL pointer (e.g. NULL). Which looks like a client error (e.g. how can SSL be NULL ? ) Maurizio On 10/11/2021 09:34, Maurizio Cimadamore wrote: > Hi, > thanks for sharing the feedback! I'm glad you got something working. > Hopefully we can fix the rest :-) > > On 10/11/2021 09:20, R?my Maucherat wrote: >> However, I am running into cores (apparently caused by memory >> corruption) with the panama-foreign branch, while the Java 17 version >> seems solid. > > That is interesting information. So, you say that the Java 17 version > works fine, but when building (latest) panama-foreign, you get some VM > crash. > > Now, looking at the crash, it seems like it occurs in the middle of a > native call: > > ``` > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > v? ~RuntimeStub::nep_invoker_blob <------------ > J 5738 c1 > org.apache.tomcat.util.openssl.openssl_h.SSL_shutdown(Ljdk/incubator/foreign/Addressable;)I > (31 bytes) @ 0x00007faf82340d2c [0x00007faf8233cc20+0x000000000000410c] > J 5482 c1 > org.apache.tomcat.util.net.openssl.panama.OpenSSLEngine.closeOutbound()V > (76 bytes) @ 0x00007faf81a934e4 [0x00007faf81a93280+0x0000000000000264] > ``` > > This area changed quite a bit recently, as we are refactoring and > consolidating the linking functionalities to make it simpler for > developers to port the CLInker implementation to other platforms. I > wonder if a regression sneaked in (possible, the refactoring were > quite big). > > In terms of support for shared scopes, the one thing that has changed > from 16 to 17 is that now if you pass arguments by reference to > functions, those references' scopes are "acquired" on function enter > and "released" on function exit - which means it is not possible, even > in a shared context, for e.g. the target address of a native function > to be unloaded in the middle of a native call. But this should add > _more_ safety, not less. > > I suppose that you tested Java 17 by using the jextract available in > the Panama EA binaries; and that you tested the bits in panama-foreign > by manually building them, and using the jextract you obtained as a > result (e.g. using the EA jextract against the latest panama-foreign > API will NOT work). > > Thanks > Maurizio > From jorn.vernee at oracle.com Wed Nov 10 13:42:38 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Wed, 10 Nov 2021 14:42:38 +0100 Subject: OpenSSL and panama-foreign In-Reply-To: <38c1be7a-dedb-6576-cdac-ea51b230dcb8@oracle.com> References: <38c1be7a-dedb-6576-cdac-ea51b230dcb8@oracle.com> Message-ID: <7b481abf-bfc4-4647-6619-4837cd3f3207@oracle.com> Looking at this, it seems there is a race between the cleaner running and the SSL_shutdown call (i.e. undefined behaviour). Note that the `this` object (which the cleanup action is registered on) can be collected as soon as it's unused in closeOutbound, and SSL_shutdown doesn't use it. You'd at least need `Reference.reachabilityFence(this)` after the call to SSL_shutdown. But, I'd suggest doing what Maurizio suggested instead. In the constructor of OpenSSLEngine: - Use ResourceScope.newImplicitScope() instead to create the scope [1] - Attach both 'ssl' and 'networkBIO' to the scope by turning them into memory segments using MemorySegment::ofAddressNative [2] - Then add a close action to the scope which frees your pointers [3] The call will keep the scope alive, which makes sure the cleanup isn't done during, or before, the native call. HTH, Jorn [1] : https://github.com/openjdk/panama-foreign/blob/foreign-jextract/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java#L247 [2] : https://github.com/openjdk/panama-foreign/blob/foreign-jextract/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java#L791 [3] : https://github.com/openjdk/panama-foreign/blob/foreign-jextract/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java#L190 On 10/11/2021 13:53, Maurizio Cimadamore wrote: > Looking more at your code, I noticed you use cleaners: > > https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L275 > > > That is, when the engine is unreacheable, you have some cleanup actions: > > https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L1868 > > > Note that you can probably achieve the same effect by registering the > scope with a cleaner, and then add a "close action" on the cleaner > itself, to close the scope. But this is an optional suggestion. > > What I find more disturbing is that the addresses you generate, e.g. > this: > > https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/openssl/openssl_h.java#L1327 > > > This `ssl` address is just a raw memory address - it doesn't have any > real temporal bounds. It is not attached to the scope you create in > any way. > > So, when you do this: > > https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L766 > > > The linker won't really protect that call in any way. There's no way > for the linker to know whether the address is still available or not. > Which might be ok if the memory is managed by SSL anyway. > > But the issue here, as your debugging session shows, is that, somehow, > you end up calling SSL_shutdown on a bad SSL pointer (e.g. NULL). > Which looks like a client error (e.g. how can SSL be NULL ? ) > > Maurizio > > > > > On 10/11/2021 09:34, Maurizio Cimadamore wrote: >> Hi, >> thanks for sharing the feedback! I'm glad you got something working. >> Hopefully we can fix the rest :-) >> >> On 10/11/2021 09:20, R?my Maucherat wrote: >>> However, I am running into cores (apparently caused by memory >>> corruption) with the panama-foreign branch, while the Java 17 version >>> seems solid. >> >> That is interesting information. So, you say that the Java 17 version >> works fine, but when building (latest) panama-foreign, you get some >> VM crash. >> >> Now, looking at the crash, it seems like it occurs in the middle of a >> native call: >> >> ``` >> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >> v? ~RuntimeStub::nep_invoker_blob <------------ >> J 5738 c1 >> org.apache.tomcat.util.openssl.openssl_h.SSL_shutdown(Ljdk/incubator/foreign/Addressable;)I >> (31 bytes) @ 0x00007faf82340d2c [0x00007faf8233cc20+0x000000000000410c] >> J 5482 c1 >> org.apache.tomcat.util.net.openssl.panama.OpenSSLEngine.closeOutbound()V >> (76 bytes) @ 0x00007faf81a934e4 [0x00007faf81a93280+0x0000000000000264] >> ``` >> >> This area changed quite a bit recently, as we are refactoring and >> consolidating the linking functionalities to make it simpler for >> developers to port the CLInker implementation to other platforms. I >> wonder if a regression sneaked in (possible, the refactoring were >> quite big). >> >> In terms of support for shared scopes, the one thing that has changed >> from 16 to 17 is that now if you pass arguments by reference to >> functions, those references' scopes are "acquired" on function enter >> and "released" on function exit - which means it is not possible, >> even in a shared context, for e.g. the target address of a native >> function to be unloaded in the middle of a native call. But this >> should add _more_ safety, not less. >> >> I suppose that you tested Java 17 by using the jextract available in >> the Panama EA binaries; and that you tested the bits in >> panama-foreign by manually building them, and using the jextract you >> obtained as a result (e.g. using the EA jextract against the latest >> panama-foreign API will NOT work). >> >> Thanks >> Maurizio >> From jorn.vernee at oracle.com Wed Nov 10 14:20:28 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Wed, 10 Nov 2021 15:20:28 +0100 Subject: OpenSSL and panama-foreign In-Reply-To: <7b481abf-bfc4-4647-6619-4837cd3f3207@oracle.com> References: <38c1be7a-dedb-6576-cdac-ea51b230dcb8@oracle.com> <7b481abf-bfc4-4647-6619-4837cd3f3207@oracle.com> Message-ID: <7ec0cb52-83b6-f7d8-7a58-cda844fe874e@oracle.com> Actually, after hitting send on my last email I noticed the method is also `synchronized` which I think will keep the cleanup action from running until the monitor is unlocked (not sure here though). So, maybe that's not it. Jorn On 10/11/2021 14:42, Jorn Vernee wrote: > Looking at this, it seems there is a race between the cleaner running > and the SSL_shutdown call (i.e. undefined behaviour). Note that the > `this` object (which the cleanup action is registered on) can be > collected as soon as it's unused in closeOutbound, and SSL_shutdown > doesn't use it. > > You'd at least need `Reference.reachabilityFence(this)` after the call > to SSL_shutdown. > > But, I'd suggest doing what Maurizio suggested instead. In the > constructor of OpenSSLEngine: > > - Use ResourceScope.newImplicitScope() instead to create the scope [1] > - Attach both 'ssl' and 'networkBIO' to the scope by turning them into > memory segments using MemorySegment::ofAddressNative [2] > - Then add a close action to the scope which frees your pointers [3] > > The call will keep the scope alive, which makes sure the cleanup isn't > done during, or before, the native call. > > HTH, > Jorn > > [1] : > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java#L247 > [2] : > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java#L791 > [3] : > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java#L190 > > On 10/11/2021 13:53, Maurizio Cimadamore wrote: >> Looking more at your code, I noticed you use cleaners: >> >> https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L275 >> >> >> That is, when the engine is unreacheable, you have some cleanup actions: >> >> https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L1868 >> >> >> Note that you can probably achieve the same effect by registering the >> scope with a cleaner, and then add a "close action" on the cleaner >> itself, to close the scope. But this is an optional suggestion. >> >> What I find more disturbing is that the addresses you generate, e.g. >> this: >> >> https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/openssl/openssl_h.java#L1327 >> >> >> This `ssl` address is just a raw memory address - it doesn't have any >> real temporal bounds. It is not attached to the scope you create in >> any way. >> >> So, when you do this: >> >> https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L766 >> >> >> The linker won't really protect that call in any way. There's no way >> for the linker to know whether the address is still available or not. >> Which might be ok if the memory is managed by SSL anyway. >> >> But the issue here, as your debugging session shows, is that, >> somehow, you end up calling SSL_shutdown on a bad SSL pointer (e.g. >> NULL). Which looks like a client error (e.g. how can SSL be NULL ? ) >> >> Maurizio >> >> >> >> >> On 10/11/2021 09:34, Maurizio Cimadamore wrote: >>> Hi, >>> thanks for sharing the feedback! I'm glad you got something working. >>> Hopefully we can fix the rest :-) >>> >>> On 10/11/2021 09:20, R?my Maucherat wrote: >>>> However, I am running into cores (apparently caused by memory >>>> corruption) with the panama-foreign branch, while the Java 17 version >>>> seems solid. >>> >>> That is interesting information. So, you say that the Java 17 >>> version works fine, but when building (latest) panama-foreign, you >>> get some VM crash. >>> >>> Now, looking at the crash, it seems like it occurs in the middle of >>> a native call: >>> >>> ``` >>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >>> v? ~RuntimeStub::nep_invoker_blob <------------ >>> J 5738 c1 >>> org.apache.tomcat.util.openssl.openssl_h.SSL_shutdown(Ljdk/incubator/foreign/Addressable;)I >>> (31 bytes) @ 0x00007faf82340d2c [0x00007faf8233cc20+0x000000000000410c] >>> J 5482 c1 >>> org.apache.tomcat.util.net.openssl.panama.OpenSSLEngine.closeOutbound()V >>> (76 bytes) @ 0x00007faf81a934e4 [0x00007faf81a93280+0x0000000000000264] >>> ``` >>> >>> This area changed quite a bit recently, as we are refactoring and >>> consolidating the linking functionalities to make it simpler for >>> developers to port the CLInker implementation to other platforms. I >>> wonder if a regression sneaked in (possible, the refactoring were >>> quite big). >>> >>> In terms of support for shared scopes, the one thing that has >>> changed from 16 to 17 is that now if you pass arguments by reference >>> to functions, those references' scopes are "acquired" on function >>> enter and "released" on function exit - which means it is not >>> possible, even in a shared context, for e.g. the target address of a >>> native function to be unloaded in the middle of a native call. But >>> this should add _more_ safety, not less. >>> >>> I suppose that you tested Java 17 by using the jextract available in >>> the Panama EA binaries; and that you tested the bits in >>> panama-foreign by manually building them, and using the jextract you >>> obtained as a result (e.g. using the EA jextract against the latest >>> panama-foreign API will NOT work). >>> >>> Thanks >>> Maurizio >>> From remm at apache.org Wed Nov 10 14:54:18 2021 From: remm at apache.org (=?UTF-8?Q?R=C3=A9my_Maucherat?=) Date: Wed, 10 Nov 2021 15:54:18 +0100 Subject: OpenSSL and panama-foreign In-Reply-To: <7ec0cb52-83b6-f7d8-7a58-cda844fe874e@oracle.com> References: <38c1be7a-dedb-6576-cdac-ea51b230dcb8@oracle.com> <7b481abf-bfc4-4647-6619-4837cd3f3207@oracle.com> <7ec0cb52-83b6-f7d8-7a58-cda844fe874e@oracle.com> Message-ID: On Wed, Nov 10, 2021 at 3:20 PM Jorn Vernee wrote: > > Actually, after hitting send on my last email I noticed the method is > also `synchronized` which I think will keep the cleanup action from > running until the monitor is unlocked (not sure here though). So, maybe > that's not it. Thanks a lot for the great design ideas. Keeping around MemorySegment instead of MemoryAddress is a much better design. I'll also use the scope as the controller for closing everything. Notes: The cleaner comes from a Java 11 finalize refactoring. The sync model was also there before with the JNI code, it worked. Overall this is a translation of the JNI calling code, the ssl there was simply a long (so not very safe ...). R?my > > Jorn > > On 10/11/2021 14:42, Jorn Vernee wrote: > > Looking at this, it seems there is a race between the cleaner running > > and the SSL_shutdown call (i.e. undefined behaviour). Note that the > > `this` object (which the cleanup action is registered on) can be > > collected as soon as it's unused in closeOutbound, and SSL_shutdown > > doesn't use it. > > > > You'd at least need `Reference.reachabilityFence(this)` after the call > > to SSL_shutdown. > > > > But, I'd suggest doing what Maurizio suggested instead. In the > > constructor of OpenSSLEngine: > > > > - Use ResourceScope.newImplicitScope() instead to create the scope [1] > > - Attach both 'ssl' and 'networkBIO' to the scope by turning them into > > memory segments using MemorySegment::ofAddressNative [2] > > - Then add a close action to the scope which frees your pointers [3] > > > > The call will keep the scope alive, which makes sure the cleanup isn't > > done during, or before, the native call. > > > > HTH, > > Jorn > > > > [1] : > > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java#L247 > > [2] : > > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java#L791 > > [3] : > > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java#L190 > > > > On 10/11/2021 13:53, Maurizio Cimadamore wrote: > >> Looking more at your code, I noticed you use cleaners: > >> > >> https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L275 > >> > >> > >> That is, when the engine is unreacheable, you have some cleanup actions: > >> > >> https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L1868 > >> > >> > >> Note that you can probably achieve the same effect by registering the > >> scope with a cleaner, and then add a "close action" on the cleaner > >> itself, to close the scope. But this is an optional suggestion. > >> > >> What I find more disturbing is that the addresses you generate, e.g. > >> this: > >> > >> https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/openssl/openssl_h.java#L1327 > >> > >> > >> This `ssl` address is just a raw memory address - it doesn't have any > >> real temporal bounds. It is not attached to the scope you create in > >> any way. > >> > >> So, when you do this: > >> > >> https://github.com/rmaucher/openssl-panama-foreign/blob/5869df2c2e58a0a4aa8e0883c1a896cd49e96146/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java#L766 > >> > >> > >> The linker won't really protect that call in any way. There's no way > >> for the linker to know whether the address is still available or not. > >> Which might be ok if the memory is managed by SSL anyway. > >> > >> But the issue here, as your debugging session shows, is that, > >> somehow, you end up calling SSL_shutdown on a bad SSL pointer (e.g. > >> NULL). Which looks like a client error (e.g. how can SSL be NULL ? ) > >> > >> Maurizio > >> > >> > >> > >> > >> On 10/11/2021 09:34, Maurizio Cimadamore wrote: > >>> Hi, > >>> thanks for sharing the feedback! I'm glad you got something working. > >>> Hopefully we can fix the rest :-) > >>> > >>> On 10/11/2021 09:20, R?my Maucherat wrote: > >>>> However, I am running into cores (apparently caused by memory > >>>> corruption) with the panama-foreign branch, while the Java 17 version > >>>> seems solid. > >>> > >>> That is interesting information. So, you say that the Java 17 > >>> version works fine, but when building (latest) panama-foreign, you > >>> get some VM crash. > >>> > >>> Now, looking at the crash, it seems like it occurs in the middle of > >>> a native call: > >>> > >>> ``` > >>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > >>> v ~RuntimeStub::nep_invoker_blob <------------ > >>> J 5738 c1 > >>> org.apache.tomcat.util.openssl.openssl_h.SSL_shutdown(Ljdk/incubator/foreign/Addressable;)I > >>> (31 bytes) @ 0x00007faf82340d2c [0x00007faf8233cc20+0x000000000000410c] > >>> J 5482 c1 > >>> org.apache.tomcat.util.net.openssl.panama.OpenSSLEngine.closeOutbound()V > >>> (76 bytes) @ 0x00007faf81a934e4 [0x00007faf81a93280+0x0000000000000264] > >>> ``` > >>> > >>> This area changed quite a bit recently, as we are refactoring and > >>> consolidating the linking functionalities to make it simpler for > >>> developers to port the CLInker implementation to other platforms. I > >>> wonder if a regression sneaked in (possible, the refactoring were > >>> quite big). > >>> > >>> In terms of support for shared scopes, the one thing that has > >>> changed from 16 to 17 is that now if you pass arguments by reference > >>> to functions, those references' scopes are "acquired" on function > >>> enter and "released" on function exit - which means it is not > >>> possible, even in a shared context, for e.g. the target address of a > >>> native function to be unloaded in the middle of a native call. But > >>> this should add _more_ safety, not less. > >>> > >>> I suppose that you tested Java 17 by using the jextract available in > >>> the Panama EA binaries; and that you tested the bits in > >>> panama-foreign by manually building them, and using the jextract you > >>> obtained as a result (e.g. using the EA jextract against the latest > >>> panama-foreign API will NOT work). > >>> > >>> Thanks > >>> Maurizio > >>> From maurizio.cimadamore at oracle.com Wed Nov 10 15:48:08 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Nov 2021 15:48:08 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: <38c1be7a-dedb-6576-cdac-ea51b230dcb8@oracle.com> <7b481abf-bfc4-4647-6619-4837cd3f3207@oracle.com> <7ec0cb52-83b6-f7d8-7a58-cda844fe874e@oracle.com> Message-ID: I see what you mean - e.g. this code is just a straight port of the JNI code. That said, it's possible that the JNI code kept alive some Java objects via JNI handles - which with Panama would no longer be true. I'd recommend to double check if, when you get a core dump, your cleanup actions are run prematurely. Right now it's a bit hard to tell given that some address are raw native addresses (w/o a lifecycle) and some do have a lifecycle (scope). But looking at your debug for the crash you got on SSL_Shutdown, I still don't get why SSL* is set to zeros (NULL). I don't think you are assigning that pointer anywhere else (OpenSSLState.ssl is final). Which seems to suggest that, somehow, that ssl pointer is set to NULL from the start, and then you get a crash when you try to do anything with it. But I agree that it looks suspicious that the behavior changed from 17. I'd suggest starting from making sure that there's just one cleanup mechanism (the scope). E.g. 1. create an implicit scope, as suggested by Jorn instead of a shared one. 2. do not register anything with a cleaner. Instead add a cleanup action, so that when the scope is closed (implicitly, by a cleaner), you call BIO_free and SSL_free on the pointers you have. 3. I think you might need to add reachability fences - because there's no guarantee that the scope would be kept reachable while you call methods on SSLEngine - the VM might detect that `this` is no longer used and then reclaim it (as Jorn mentioned, I'm not sure if relying on synchronized blocks is enough for this) In other words, let's simplify the lifecycle management a bit, so that we can rule out e.g. that the scope is close _while_ one of the native call is taking place. If we do that, and we still get a crash, that might point to a real regression - as things are, it's hard to tell - it might just have been a latent bug which now became more manifest. Maurizio On 10/11/2021 14:54, R?my Maucherat wrote: > Thanks a lot for the great design ideas. Keeping around MemorySegment > instead of MemoryAddress is a much better design. I'll also use the > scope as the controller for closing everything. > > Notes: The cleaner comes from a Java 11 finalize refactoring. The sync > model was also there before with the JNI code, it worked. Overall this > is a translation of the JNI calling code, the ssl there was simply a > long (so not very safe ...). From maurizio.cimadamore at oracle.com Wed Nov 10 16:39:58 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Nov 2021 16:39:58 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: <38c1be7a-dedb-6576-cdac-ea51b230dcb8@oracle.com> <7b481abf-bfc4-4647-6619-4837cd3f3207@oracle.com> <7ec0cb52-83b6-f7d8-7a58-cda844fe874e@oracle.com> Message-ID: <17d48f3d-bcbd-96ea-1769-660ae17100ad@oracle.com> For the records, I'm on Linux, so if you can put together a test case maybe with just SSL engine (e.g. no tomcat) which is enough to reproduce the problem, I'm happy to give it a try and do some debugging. Maurizio On 10/11/2021 15:48, Maurizio Cimadamore wrote: > > I see what you mean - e.g. this code is just a straight port of the > JNI code. > > That said, it's possible that the JNI code kept alive some Java > objects via JNI handles - which with Panama would no longer be true. > > I'd recommend to double check if, when you get a core dump, your > cleanup actions are run prematurely. Right now it's a bit hard to tell > given that some address are raw native addresses (w/o a lifecycle) and > some do have a lifecycle (scope). > > But looking at your debug for the crash you got on SSL_Shutdown, I > still don't get why SSL* is set to zeros (NULL). I don't think you are > assigning that pointer anywhere else (OpenSSLState.ssl is final). > > Which seems to suggest that, somehow, that ssl pointer is set to NULL > from the start, and then you get a crash when you try to do anything > with it. > > But I agree that it looks suspicious that the behavior changed from 17. > > I'd suggest starting from making sure that there's just one cleanup > mechanism (the scope). E.g. > > 1. create an implicit scope, as suggested by Jorn instead of a shared one. > 2. do not register anything with a cleaner. Instead add a cleanup > action, so that when the scope is closed (implicitly, by a cleaner), > you call BIO_free and SSL_free on the pointers you have. > 3. I think you might need to add reachability fences - because there's > no guarantee that the scope would be kept reachable while you call > methods on SSLEngine - the VM might detect that `this` is no longer > used and then reclaim it (as Jorn mentioned, I'm not sure if relying > on synchronized blocks is enough for this) > > In other words, let's simplify the lifecycle management a bit, so that > we can rule out e.g. that the scope is close _while_ one of the native > call is taking place. If we do that, and we still get a crash, that > might point to a real regression - as things are, it's hard to tell - > it might just have been a latent bug which now became more manifest. > > Maurizio > > > On 10/11/2021 14:54, R?my Maucherat wrote: >> Thanks a lot for the great design ideas. Keeping around MemorySegment >> instead of MemoryAddress is a much better design. I'll also use the >> scope as the controller for closing everything. >> >> Notes: The cleaner comes from a Java 11 finalize refactoring. The sync >> model was also there before with the JNI code, it worked. Overall this >> is a translation of the JNI calling code, the ssl there was simply a >> long (so not very safe ...). From maurizio.cimadamore at oracle.com Wed Nov 10 17:03:29 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Nov 2021 17:03:29 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: Message-ID: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> This looks really odd. The crash happens at line 4420. But `s` has already been dereferenced e.g. in 4408 and 4413. This smells of something stomping on the stack? It would help a lot if you could try the panama-foreign version against the JDK 18 PR we have here: https://git.openjdk.java.net/jdk/pull/5907 This is like panama-foreign _minus_ the latest VM changes (e.g. VM support is like that in 17). If the above PR works but Panama doesn't, I think then we're staring at a regression in the linker runtime. Maurizio On 10/11/2021 11:20, R?my Maucherat wrote: > In gdb, the debug is: > > #10 ssl3_shutdown (s=0x0) at ssl/s3_lib.c:4420 > 4420 if (s->s3->alert_dispatch) > (gdb) print s > $1 = (SSL *) 0x0 > > With the corresponding source: > 4400 int ssl3_shutdown(SSL *s) > 4401 { > 4402 int ret; > 4403 > 4404 /* > 4405 * Don't do anything much if we have not done the > handshake or we don't > 4406 * want to send messages:-) > 4407 */ > 4408 if (s->quiet_shutdown || SSL_in_before(s)) { > 4409 s->shutdown = (SSL_SENT_SHUTDOWN | SSL_RECEIVED_SHUTDOWN); > 4410 return 1; > 4411 } > 4412 > 4413 if (!(s->shutdown & SSL_SENT_SHUTDOWN)) { > 4414 s->shutdown |= SSL_SENT_SHUTDOWN; > 4415 ssl3_send_alert(s, SSL3_AL_WARNING, SSL_AD_CLOSE_NOTIFY); > 4416 /* > 4417 * our shutdown alert has been sent now, and if it > still needs to be > 4418 * written, s->s3->alert_dispatch will be true > 4419 */ > 4420 if (s->s3->alert_dispatch) > 4421 return -1; /* return WANT_WRITE */ > 4422 } else if (s->s3->alert_dispatch) { > 4423 /* resend it if not sent */ > 4424 ret = s->method->ssl_dispatch_alert(s); > 4425 if (ret == -1) { > 4426 /* > 4427 * we only get to return -1 here the 2nd/Nth > invocation, we must > 4428 * have already signalled return 0 upon a previous > invocation, > 4429 * return WANT_WRITE > 4430 */ > 4431 return ret; > 4432 } From remm at apache.org Wed Nov 10 17:43:55 2021 From: remm at apache.org (=?UTF-8?Q?R=C3=A9my_Maucherat?=) Date: Wed, 10 Nov 2021 18:43:55 +0100 Subject: OpenSSL and panama-foreign In-Reply-To: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> Message-ID: On Wed, Nov 10, 2021 at 6:03 PM Maurizio Cimadamore wrote: > > This looks really odd. > > The crash happens at line 4420. But `s` has already been dereferenced > e.g. in 4408 and 4413. > > This smells of something stomping on the stack? > > It would help a lot if you could try the panama-foreign version against > the JDK 18 PR we have here: > > https://git.openjdk.java.net/jdk/pull/5907 > > This is like panama-foreign _minus_ the latest VM changes (e.g. VM > support is like that in 17). > > If the above PR works but Panama doesn't, I think then we're staring at > a regression in the linker runtime. Ok, quick test then since this is very interesting. It cores (exact same ones). I'll work on all the other items now (thanks for all the homework ;) ). R?my > > Maurizio > > On 10/11/2021 11:20, R?my Maucherat wrote: > > In gdb, the debug is: > > > > #10 ssl3_shutdown (s=0x0) at ssl/s3_lib.c:4420 > > 4420 if (s->s3->alert_dispatch) > > (gdb) print s > > $1 = (SSL *) 0x0 > > > > With the corresponding source: > > 4400 int ssl3_shutdown(SSL *s) > > 4401 { > > 4402 int ret; > > 4403 > > 4404 /* > > 4405 * Don't do anything much if we have not done the > > handshake or we don't > > 4406 * want to send messages:-) > > 4407 */ > > 4408 if (s->quiet_shutdown || SSL_in_before(s)) { > > 4409 s->shutdown = (SSL_SENT_SHUTDOWN | SSL_RECEIVED_SHUTDOWN); > > 4410 return 1; > > 4411 } > > 4412 > > 4413 if (!(s->shutdown & SSL_SENT_SHUTDOWN)) { > > 4414 s->shutdown |= SSL_SENT_SHUTDOWN; > > 4415 ssl3_send_alert(s, SSL3_AL_WARNING, SSL_AD_CLOSE_NOTIFY); > > 4416 /* > > 4417 * our shutdown alert has been sent now, and if it > > still needs to be > > 4418 * written, s->s3->alert_dispatch will be true > > 4419 */ > > 4420 if (s->s3->alert_dispatch) > > 4421 return -1; /* return WANT_WRITE */ > > 4422 } else if (s->s3->alert_dispatch) { > > 4423 /* resend it if not sent */ > > 4424 ret = s->method->ssl_dispatch_alert(s); > > 4425 if (ret == -1) { > > 4426 /* > > 4427 * we only get to return -1 here the 2nd/Nth > > invocation, we must > > 4428 * have already signalled return 0 upon a previous > > invocation, > > 4429 * return WANT_WRITE > > 4430 */ > > 4431 return ret; > > 4432 } From maurizio.cimadamore at oracle.com Wed Nov 10 17:56:18 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Nov 2021 17:56:18 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> Message-ID: <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> > Ok, quick test then since this is very interesting. It cores (exact same ones). > > I'll work on all the other items now (thanks for all the homework ;) ). Thanks for testing. This leaves us with two options: some general JDK change which brought some latent issue to the fore, or some specific regression in the linker support. On top of my head the latter doesn't make much sense - since the new panama changes only affect the API, not the VM internals. But I'll keep testing on my end. Maurizio > > R?my > >> Maurizio >> >> On 10/11/2021 11:20, R?my Maucherat wrote: >>> In gdb, the debug is: >>> >>> #10 ssl3_shutdown (s=0x0) at ssl/s3_lib.c:4420 >>> 4420 if (s->s3->alert_dispatch) >>> (gdb) print s >>> $1 = (SSL *) 0x0 >>> >>> With the corresponding source: >>> 4400 int ssl3_shutdown(SSL *s) >>> 4401 { >>> 4402 int ret; >>> 4403 >>> 4404 /* >>> 4405 * Don't do anything much if we have not done the >>> handshake or we don't >>> 4406 * want to send messages:-) >>> 4407 */ >>> 4408 if (s->quiet_shutdown || SSL_in_before(s)) { >>> 4409 s->shutdown = (SSL_SENT_SHUTDOWN | SSL_RECEIVED_SHUTDOWN); >>> 4410 return 1; >>> 4411 } >>> 4412 >>> 4413 if (!(s->shutdown & SSL_SENT_SHUTDOWN)) { >>> 4414 s->shutdown |= SSL_SENT_SHUTDOWN; >>> 4415 ssl3_send_alert(s, SSL3_AL_WARNING, SSL_AD_CLOSE_NOTIFY); >>> 4416 /* >>> 4417 * our shutdown alert has been sent now, and if it >>> still needs to be >>> 4418 * written, s->s3->alert_dispatch will be true >>> 4419 */ >>> 4420 if (s->s3->alert_dispatch) >>> 4421 return -1; /* return WANT_WRITE */ >>> 4422 } else if (s->s3->alert_dispatch) { >>> 4423 /* resend it if not sent */ >>> 4424 ret = s->method->ssl_dispatch_alert(s); >>> 4425 if (ret == -1) { >>> 4426 /* >>> 4427 * we only get to return -1 here the 2nd/Nth >>> invocation, we must >>> 4428 * have already signalled return 0 upon a previous >>> invocation, >>> 4429 * return WANT_WRITE >>> 4430 */ >>> 4431 return ret; >>> 4432 } From maurizio.cimadamore at oracle.com Wed Nov 10 18:19:26 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Nov 2021 18:19:26 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> Message-ID: I've been able to reproduce, with tomcat and all. Seeing all the crashes you are seeing. After some digging, it seems like the crash does not occur with these parameters: export JAVA_OPTS="-Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign" In other words, the intrinsification support for _upcalls_ seems to be creating issues here. Please confirm that this setup works for you. Cheers Maurizio On 10/11/2021 17:56, Maurizio Cimadamore wrote: > >> Ok, quick test then since this is very interesting. It cores (exact >> same ones). >> >> I'll work on all the other items now (thanks for all the homework ;) ). > > Thanks for testing. This leaves us with two options: some general JDK > change which brought some latent issue to the fore, or some specific > regression in the linker support. On top of my head the latter doesn't > make much sense - since the new panama changes only affect the API, > not the VM internals. > > But I'll keep testing on my end. > > Maurizio > > >> >> R?my >> >>> Maurizio >>> >>> On 10/11/2021 11:20, R?my Maucherat wrote: >>>> In gdb, the debug is: >>>> >>>> #10 ssl3_shutdown (s=0x0) at ssl/s3_lib.c:4420 >>>> 4420??????????? if (s->s3->alert_dispatch) >>>> (gdb) print s >>>> $1 = (SSL *) 0x0 >>>> >>>> With the corresponding source: >>>> 4400??? int ssl3_shutdown(SSL *s) >>>> 4401??? { >>>> 4402??????? int ret; >>>> 4403 >>>> 4404??????? /* >>>> 4405???????? * Don't do anything much if we have not done the >>>> handshake or we don't >>>> 4406???????? * want to send messages:-) >>>> 4407???????? */ >>>> 4408??????? if (s->quiet_shutdown || SSL_in_before(s)) { >>>> 4409??????????? s->shutdown = (SSL_SENT_SHUTDOWN | >>>> SSL_RECEIVED_SHUTDOWN); >>>> 4410??????????? return 1; >>>> 4411??????? } >>>> 4412 >>>> 4413??????? if (!(s->shutdown & SSL_SENT_SHUTDOWN)) { >>>> 4414??????????? s->shutdown |= SSL_SENT_SHUTDOWN; >>>> 4415??????????? ssl3_send_alert(s, SSL3_AL_WARNING, >>>> SSL_AD_CLOSE_NOTIFY); >>>> 4416??????????? /* >>>> 4417???????????? * our shutdown alert has been sent now, and if it >>>> still needs to be >>>> 4418???????????? * written, s->s3->alert_dispatch will be true >>>> 4419???????????? */ >>>> 4420??????????? if (s->s3->alert_dispatch) >>>> 4421??????????????? return -1;??????? /* return WANT_WRITE */ >>>> 4422??????? } else if (s->s3->alert_dispatch) { >>>> 4423??????????? /* resend it if not sent */ >>>> 4424??????????? ret = s->method->ssl_dispatch_alert(s); >>>> 4425??????????? if (ret == -1) { >>>> 4426??????????????? /* >>>> 4427???????????????? * we only get to return -1 here the 2nd/Nth >>>> invocation, we must >>>> 4428???????????????? * have already signalled return 0 upon a previous >>>> invocation, >>>> 4429???????????????? * return WANT_WRITE >>>> 4430???????????????? */ >>>> 4431??????????????? return ret; >>>> 4432??????????? } From remm at apache.org Wed Nov 10 19:09:35 2021 From: remm at apache.org (=?UTF-8?Q?R=C3=A9my_Maucherat?=) Date: Wed, 10 Nov 2021 20:09:35 +0100 Subject: OpenSSL and panama-foreign In-Reply-To: References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> Message-ID: On Wed, Nov 10, 2021 at 7:19 PM Maurizio Cimadamore wrote: > > I've been able to reproduce, with tomcat and all. Seeing all the crashes > you are seeing. > > After some digging, it seems like the crash does not occur with these > parameters: > > export > JAVA_OPTS="-Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false > --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign" > > In other words, the intrinsification support for _upcalls_ seems to be > creating issues here. > > Please confirm that this setup works for you. I can confirm the setting fixes the problem (using the PR, I didn't switch back to the panama-foreign branch). Great job on catching it ! R?my > > Cheers > Maurizio > > > On 10/11/2021 17:56, Maurizio Cimadamore wrote: > > > >> Ok, quick test then since this is very interesting. It cores (exact > >> same ones). > >> > >> I'll work on all the other items now (thanks for all the homework ;) ). > > > > Thanks for testing. This leaves us with two options: some general JDK > > change which brought some latent issue to the fore, or some specific > > regression in the linker support. On top of my head the latter doesn't > > make much sense - since the new panama changes only affect the API, > > not the VM internals. > > > > But I'll keep testing on my end. > > > > Maurizio > > > > > >> > >> R?my > >> > >>> Maurizio > >>> > >>> On 10/11/2021 11:20, R?my Maucherat wrote: > >>>> In gdb, the debug is: > >>>> > >>>> #10 ssl3_shutdown (s=0x0) at ssl/s3_lib.c:4420 > >>>> 4420 if (s->s3->alert_dispatch) > >>>> (gdb) print s > >>>> $1 = (SSL *) 0x0 > >>>> > >>>> With the corresponding source: > >>>> 4400 int ssl3_shutdown(SSL *s) > >>>> 4401 { > >>>> 4402 int ret; > >>>> 4403 > >>>> 4404 /* > >>>> 4405 * Don't do anything much if we have not done the > >>>> handshake or we don't > >>>> 4406 * want to send messages:-) > >>>> 4407 */ > >>>> 4408 if (s->quiet_shutdown || SSL_in_before(s)) { > >>>> 4409 s->shutdown = (SSL_SENT_SHUTDOWN | > >>>> SSL_RECEIVED_SHUTDOWN); > >>>> 4410 return 1; > >>>> 4411 } > >>>> 4412 > >>>> 4413 if (!(s->shutdown & SSL_SENT_SHUTDOWN)) { > >>>> 4414 s->shutdown |= SSL_SENT_SHUTDOWN; > >>>> 4415 ssl3_send_alert(s, SSL3_AL_WARNING, > >>>> SSL_AD_CLOSE_NOTIFY); > >>>> 4416 /* > >>>> 4417 * our shutdown alert has been sent now, and if it > >>>> still needs to be > >>>> 4418 * written, s->s3->alert_dispatch will be true > >>>> 4419 */ > >>>> 4420 if (s->s3->alert_dispatch) > >>>> 4421 return -1; /* return WANT_WRITE */ > >>>> 4422 } else if (s->s3->alert_dispatch) { > >>>> 4423 /* resend it if not sent */ > >>>> 4424 ret = s->method->ssl_dispatch_alert(s); > >>>> 4425 if (ret == -1) { > >>>> 4426 /* > >>>> 4427 * we only get to return -1 here the 2nd/Nth > >>>> invocation, we must > >>>> 4428 * have already signalled return 0 upon a previous > >>>> invocation, > >>>> 4429 * return WANT_WRITE > >>>> 4430 */ > >>>> 4431 return ret; > >>>> 4432 } From maurizio.cimadamore at oracle.com Wed Nov 10 22:27:22 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Nov 2021 22:27:22 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> Message-ID: After many failed attempts at narrowing it down, I change direction and commented this line on panama-foreign https://github.com/openjdk/panama-foreign/blob/ea1e0d6e62558d31084250ce07c2334f6f8ebc0f/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java#L116 That is, I removed the shared scope handshake. Without the handshake, there's no more crashes. This seems to point at some issues with the shared scope logic interacting badly with upcall intrinsics. But neither areas have changed significantly since 17, which makes this very odd. Maurizio On 10/11/2021 19:09, R?my Maucherat wrote: > On Wed, Nov 10, 2021 at 7:19 PM Maurizio Cimadamore > wrote: >> I've been able to reproduce, with tomcat and all. Seeing all the crashes >> you are seeing. >> >> After some digging, it seems like the crash does not occur with these >> parameters: >> >> export >> JAVA_OPTS="-Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false >> --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign" >> >> In other words, the intrinsification support for _upcalls_ seems to be >> creating issues here. >> >> Please confirm that this setup works for you. > I can confirm the setting fixes the problem (using the PR, I didn't > switch back to the panama-foreign branch). Great job on catching it ! > > R?my > >> Cheers >> Maurizio >> >> >> On 10/11/2021 17:56, Maurizio Cimadamore wrote: >>>> Ok, quick test then since this is very interesting. It cores (exact >>>> same ones). >>>> >>>> I'll work on all the other items now (thanks for all the homework ;) ). >>> Thanks for testing. This leaves us with two options: some general JDK >>> change which brought some latent issue to the fore, or some specific >>> regression in the linker support. On top of my head the latter doesn't >>> make much sense - since the new panama changes only affect the API, >>> not the VM internals. >>> >>> But I'll keep testing on my end. >>> >>> Maurizio >>> >>> >>>> R?my >>>> >>>>> Maurizio >>>>> >>>>> On 10/11/2021 11:20, R?my Maucherat wrote: >>>>>> In gdb, the debug is: >>>>>> >>>>>> #10 ssl3_shutdown (s=0x0) at ssl/s3_lib.c:4420 >>>>>> 4420 if (s->s3->alert_dispatch) >>>>>> (gdb) print s >>>>>> $1 = (SSL *) 0x0 >>>>>> >>>>>> With the corresponding source: >>>>>> 4400 int ssl3_shutdown(SSL *s) >>>>>> 4401 { >>>>>> 4402 int ret; >>>>>> 4403 >>>>>> 4404 /* >>>>>> 4405 * Don't do anything much if we have not done the >>>>>> handshake or we don't >>>>>> 4406 * want to send messages:-) >>>>>> 4407 */ >>>>>> 4408 if (s->quiet_shutdown || SSL_in_before(s)) { >>>>>> 4409 s->shutdown = (SSL_SENT_SHUTDOWN | >>>>>> SSL_RECEIVED_SHUTDOWN); >>>>>> 4410 return 1; >>>>>> 4411 } >>>>>> 4412 >>>>>> 4413 if (!(s->shutdown & SSL_SENT_SHUTDOWN)) { >>>>>> 4414 s->shutdown |= SSL_SENT_SHUTDOWN; >>>>>> 4415 ssl3_send_alert(s, SSL3_AL_WARNING, >>>>>> SSL_AD_CLOSE_NOTIFY); >>>>>> 4416 /* >>>>>> 4417 * our shutdown alert has been sent now, and if it >>>>>> still needs to be >>>>>> 4418 * written, s->s3->alert_dispatch will be true >>>>>> 4419 */ >>>>>> 4420 if (s->s3->alert_dispatch) >>>>>> 4421 return -1; /* return WANT_WRITE */ >>>>>> 4422 } else if (s->s3->alert_dispatch) { >>>>>> 4423 /* resend it if not sent */ >>>>>> 4424 ret = s->method->ssl_dispatch_alert(s); >>>>>> 4425 if (ret == -1) { >>>>>> 4426 /* >>>>>> 4427 * we only get to return -1 here the 2nd/Nth >>>>>> invocation, we must >>>>>> 4428 * have already signalled return 0 upon a previous >>>>>> invocation, >>>>>> 4429 * return WANT_WRITE >>>>>> 4430 */ >>>>>> 4431 return ret; >>>>>> 4432 } From maurizio.cimadamore at oracle.com Wed Nov 10 22:38:14 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Nov 2021 22:38:14 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> Message-ID: And, on this same vein, even with the resource scope handshake disabled, Tomcat still crashes with the following Java option: export JAVA_OPTS="-XX:+DeoptimizeALot --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign" DeoptimizeALot causes frequent deopt events in the VM. The handshake we use for shared segments also used deopt events. Something got broken here and the upcall intrinsic doesn't seem to be able to handle deopt events. Maurizio On 10/11/2021 22:27, Maurizio Cimadamore wrote: > This seems to point at some issues with the shared scope logic > interacting badly with upcall intrinsics. But neither areas have > changed significantly since 17, which makes this very odd. From maurizio.cimadamore at oracle.com Thu Nov 11 01:52:40 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Nov 2021 01:52:40 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> Message-ID: <60c217bc-2fa8-c1f9-080e-fe3342ce47b2@oracle.com> I think I managed to figure out what introduced the regression. Basically, it's down to the removal of customization for upcall stubs. ``` @@ -123,7 +120,7 @@ public static UpcallHandler make(ABIDescriptor abi, MethodHandle target, Calling .anyMatch(s -> abi.arch.isStackType(s.type())); if (USE_INTRINSICS && isSimple && !usesStackArgs && supportsOptimizedUpcalls()) { checkPrimitive(doBindings.type()); - JLI.ensureCustomized(doBindings); + doBindings = insertArguments(exactInvoker(doBindings.type()), 0, doBindings); VMStorage[] args = Arrays.stream(argMoves).map(Binding.Move::storage).toArray(VMStorage[]::new); VMStorage[] rets = Arrays.stream(retMoves).map(Binding.Move::storage).toArray(VMStorage[]::new); CallRegs conv = new CallRegs(args, rets); ``` If this patch is reverted, then everything works as expected (I've run your `ab` test 10 consecutive times, no crashes). Which seems like a latent bug in the upcall machinery. That said, I think that, for the time being, it would be best to revert this code to what it was in 17, to avoid these spurious crashes. I wonder if the reason behind the issue we're seeing is caused by the Addressable vs. MemoryAddress mismatch in the method type - e.g. maybe `exactInvoker(doBindings.type())` doesn't do what we think it should. I'll keep investigating tomorrow (well, later today :-) ). Cheers Maurizio On 10/11/2021 22:38, Maurizio Cimadamore wrote: > And, on this same vein, even with the resource scope handshake > disabled, Tomcat still crashes with the following Java option: > > export JAVA_OPTS="-XX:+DeoptimizeALot > --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign" > > DeoptimizeALot causes frequent deopt events in the VM. The handshake > we use for shared segments also used deopt events. Something got > broken here and the upcall intrinsic doesn't seem to be able to handle > deopt events. > > Maurizio > > > On 10/11/2021 22:27, Maurizio Cimadamore wrote: >> This seems to point at some issues with the shared scope logic >> interacting badly with upcall intrinsics. But neither areas have >> changed significantly since 17, which makes this very odd. From jbhateja at openjdk.java.net Thu Nov 11 04:26:57 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 11 Nov 2021 04:26:57 GMT Subject: [vectorIntrinsics+compress] Integrated: Merge panama-vector:vectorIntrinsics In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 05:51:13 GMT, Jatin Bhateja wrote: > Merge latest code from vectorIntrinsics into vectorIntrinsics+compress branch > > Thanks, > Jatin This pull request has now been integrated. Changeset: 083d5eb8 Author: Jatin Bhateja URL: https://git.openjdk.java.net/panama-vector/commit/083d5eb81bc8fe701fde4802f47b7fab784095e7 Stats: 6674 lines in 39 files changed: 3836 ins; 2838 del; 0 mod Merge panama-vector:vectorIntrinsics Reviewed-by: eliu ------------- PR: https://git.openjdk.java.net/panama-vector/pull/161 From maurizio.cimadamore at oracle.com Thu Nov 11 14:01:35 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Nov 2021 14:01:35 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: <60c217bc-2fa8-c1f9-080e-fe3342ce47b2@oracle.com> References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> <60c217bc-2fa8-c1f9-080e-fe3342ce47b2@oracle.com> Message-ID: <9b6bc3f1-45ea-bd22-382e-65813884ac76@oracle.com> Hi Remy, I've updated the PR: https://git.openjdk.java.net/jdk/pull/5907 With the fix discussed below. Your reproducer seems to work fine on my end - but it would be great if you could confirm either way. Thanks! Maurizio On 11/11/2021 01:52, Maurizio Cimadamore wrote: > I think I managed to figure out what introduced the regression. > > Basically, it's down to the removal of customization for upcall stubs. > > ``` > > @@ -123,7 +120,7 @@ public static UpcallHandler make(ABIDescriptor > abi, MethodHandle target, Calling > ???????????????? .anyMatch(s -> abi.arch.isStackType(s.type())); > ???????? if (USE_INTRINSICS && isSimple && !usesStackArgs && > supportsOptimizedUpcalls()) { > ???????????? checkPrimitive(doBindings.type()); > -??????????? JLI.ensureCustomized(doBindings); > +??????????? doBindings = > insertArguments(exactInvoker(doBindings.type()), 0, doBindings); > ???????????? VMStorage[] args = > Arrays.stream(argMoves).map(Binding.Move::storage).toArray(VMStorage[]::new); > ???????????? VMStorage[] rets = > Arrays.stream(retMoves).map(Binding.Move::storage).toArray(VMStorage[]::new); > ???????????? CallRegs conv = new CallRegs(args, rets); > > ``` > > If this patch is reverted, then everything works as expected (I've run > your `ab` test 10 consecutive times, no crashes). Which seems like a > latent bug in the upcall machinery. > > That said, I think that, for the time being, it would be best to > revert this code to what it was in 17, to avoid these spurious crashes. > > I wonder if the reason behind the issue we're seeing is caused by the > Addressable vs. MemoryAddress mismatch in the method type - e.g. maybe > `exactInvoker(doBindings.type())` doesn't do what we think it should. > I'll keep investigating tomorrow (well, later today :-) ). > > Cheers > Maurizio > > On 10/11/2021 22:38, Maurizio Cimadamore wrote: >> And, on this same vein, even with the resource scope handshake >> disabled, Tomcat still crashes with the following Java option: >> >> export JAVA_OPTS="-XX:+DeoptimizeALot >> --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign" >> >> DeoptimizeALot causes frequent deopt events in the VM. The handshake >> we use for shared segments also used deopt events. Something got >> broken here and the upcall intrinsic doesn't seem to be able to >> handle deopt events. >> >> Maurizio >> >> >> On 10/11/2021 22:27, Maurizio Cimadamore wrote: >>> This seems to point at some issues with the shared scope logic >>> interacting badly with upcall intrinsics. But neither areas have >>> changed significantly since 17, which makes this very odd. From remm at apache.org Thu Nov 11 14:32:41 2021 From: remm at apache.org (=?UTF-8?Q?R=C3=A9my_Maucherat?=) Date: Thu, 11 Nov 2021 15:32:41 +0100 Subject: OpenSSL and panama-foreign In-Reply-To: <9b6bc3f1-45ea-bd22-382e-65813884ac76@oracle.com> References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> <60c217bc-2fa8-c1f9-080e-fe3342ce47b2@oracle.com> <9b6bc3f1-45ea-bd22-382e-65813884ac76@oracle.com> Message-ID: On Thu, Nov 11, 2021 at 3:01 PM Maurizio Cimadamore wrote: > > Hi Remy, > I've updated the PR: > > https://git.openjdk.java.net/jdk/pull/5907 > > With the fix discussed below. > > Your reproducer seems to work fine on my end - but it would be great if > you could confirm either way. It works great. I can see it is consistently a bit faster than the Java 17 branch. R?my > > Thanks! > Maurizio > > On 11/11/2021 01:52, Maurizio Cimadamore wrote: > > I think I managed to figure out what introduced the regression. > > > > Basically, it's down to the removal of customization for upcall stubs. > > > > ``` > > > > @@ -123,7 +120,7 @@ public static UpcallHandler make(ABIDescriptor > > abi, MethodHandle target, Calling > > .anyMatch(s -> abi.arch.isStackType(s.type())); > > if (USE_INTRINSICS && isSimple && !usesStackArgs && > > supportsOptimizedUpcalls()) { > > checkPrimitive(doBindings.type()); > > - JLI.ensureCustomized(doBindings); > > + doBindings = > > insertArguments(exactInvoker(doBindings.type()), 0, doBindings); > > VMStorage[] args = > > Arrays.stream(argMoves).map(Binding.Move::storage).toArray(VMStorage[]::new); > > VMStorage[] rets = > > Arrays.stream(retMoves).map(Binding.Move::storage).toArray(VMStorage[]::new); > > CallRegs conv = new CallRegs(args, rets); > > > > ``` > > > > If this patch is reverted, then everything works as expected (I've run > > your `ab` test 10 consecutive times, no crashes). Which seems like a > > latent bug in the upcall machinery. > > > > That said, I think that, for the time being, it would be best to > > revert this code to what it was in 17, to avoid these spurious crashes. > > > > I wonder if the reason behind the issue we're seeing is caused by the > > Addressable vs. MemoryAddress mismatch in the method type - e.g. maybe > > `exactInvoker(doBindings.type())` doesn't do what we think it should. > > I'll keep investigating tomorrow (well, later today :-) ). > > > > Cheers > > Maurizio > > > > On 10/11/2021 22:38, Maurizio Cimadamore wrote: > >> And, on this same vein, even with the resource scope handshake > >> disabled, Tomcat still crashes with the following Java option: > >> > >> export JAVA_OPTS="-XX:+DeoptimizeALot > >> --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign" > >> > >> DeoptimizeALot causes frequent deopt events in the VM. The handshake > >> we use for shared segments also used deopt events. Something got > >> broken here and the upcall intrinsic doesn't seem to be able to > >> handle deopt events. > >> > >> Maurizio > >> > >> > >> On 10/11/2021 22:27, Maurizio Cimadamore wrote: > >>> This seems to point at some issues with the shared scope logic > >>> interacting badly with upcall intrinsics. But neither areas have > >>> changed significantly since 17, which makes this very odd. From remm at apache.org Thu Nov 11 14:41:24 2021 From: remm at apache.org (=?UTF-8?Q?R=C3=A9my_Maucherat?=) Date: Thu, 11 Nov 2021 15:41:24 +0100 Subject: OpenSSL and panama-foreign In-Reply-To: <60c217bc-2fa8-c1f9-080e-fe3342ce47b2@oracle.com> References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> <60c217bc-2fa8-c1f9-080e-fe3342ce47b2@oracle.com> Message-ID: On Thu, Nov 11, 2021 at 2:53 AM Maurizio Cimadamore wrote: > > I think I managed to figure out what introduced the regression. > > Basically, it's down to the removal of customization for upcall stubs. > > ``` > > @@ -123,7 +120,7 @@ public static UpcallHandler make(ABIDescriptor abi, MethodHandle target, Calling > .anyMatch(s -> abi.arch.isStackType(s.type())); > if (USE_INTRINSICS && isSimple && !usesStackArgs && supportsOptimizedUpcalls()) { > checkPrimitive(doBindings.type()); > - JLI.ensureCustomized(doBindings); > + doBindings = insertArguments(exactInvoker(doBindings.type()), 0, doBindings); > VMStorage[] args = Arrays.stream(argMoves).map(Binding.Move::storage).toArray(VMStorage[]::new); > VMStorage[] rets = Arrays.stream(retMoves).map(Binding.Move::storage).toArray(VMStorage[]::new); > CallRegs conv = new CallRegs(args, rets); > > ``` One line fixes are the best ! > > If this patch is reverted, then everything works as expected (I've run your `ab` test 10 consecutive times, no crashes). Which seems like a latent bug in the upcall machinery. > > That said, I think that, for the time being, it would be best to revert this code to what it was in 17, to avoid these spurious crashes. > > I wonder if the reason behind the issue we're seeing is caused by the Addressable vs. MemoryAddress mismatch in the method type - e.g. maybe `exactInvoker(doBindings.type())` doesn't do what we think it should. I'll keep investigating tomorrow (well, later today :-) ). > That reminds me of some upcall trouble I had with return types. Until recently on panama-foreign, I had to use long for non primitive types (a hack to fit a pointer, it worked ...) since nothing else was working. Now I can use Addressable. With Java 17, MemoryAddress works fine. > 1. create an implicit scope, as suggested by Jorn instead of a shared one. > 2. do not register anything with a cleaner. Instead add a cleanup action, so that when the scope is closed (implicitly, by a cleaner), you call BIO_free and SSL_free on the pointers you have. > 3. I think you might need to add reachability fences - because there's no guarantee that the scope would be kept reachable while you call methods on SSLEngine - the VM might detect that `this` is no longer used and then reclaim it (as Jorn mentioned, I'm not sure if relying on synchronized blocks is enough for this) > Unless I missed something the API has a side effect with upcalls. I understand after reading the javadoc where the suggestion comes from, as it makes memory management very much like Java. This is of course excellent. However, I use upcalls (as you know) and many of them are bound to an instance (since this makes state tracking very very nice). This however creates a reference that never goes away and an implicit scope is never going to get GCed and closed (I saw that with visualvm) and memory leaks. Initially I was planning to use a static Map for my state (OpenSSL allows passing references and getting them in callbacks, but this is a lot handier in C and doesn't make a lot of sense in Java), then I found MethodHandle.bindTo actually worked and this is quite magical. So with that in mind, what is the recommendation ? Should the API provide a way to remove the MethodHandle upcall ? Or should I avoid using bindTo instead ? R?my R?my > Cheers > Maurizio > > On 10/11/2021 22:38, Maurizio Cimadamore wrote: > > And, on this same vein, even with the resource scope handshake disabled, Tomcat still crashes with the following Java option: > > export JAVA_OPTS="-XX:+DeoptimizeALot --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign" > > DeoptimizeALot causes frequent deopt events in the VM. The handshake we use for shared segments also used deopt events. Something got broken here and the upcall intrinsic doesn't seem to be able to handle deopt events. > > Maurizio > > > On 10/11/2021 22:27, Maurizio Cimadamore wrote: > > This seems to point at some issues with the shared scope logic interacting badly with upcall intrinsics. But neither areas have changed significantly since 17, which makes this very odd. From magnus.ihse.bursie at oracle.com Thu Nov 11 15:02:54 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 11 Nov 2021 16:02:54 +0100 Subject: RFR: 8277015: Use blessed modifier order in Panama code In-Reply-To: References: Message-ID: I assume this is relevant for panama-dev as well, but I can't unfortunately tag the issue as such in Github/Skara. (Maybe we should have a mapping for jdk.incubator.vector/foreign -> panama-dev?) /Magnus On 2021-11-11 15:57, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. > > In this case, while the script did into the "correct" thing, it turns out that the method signatures in `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` has some room for improvement... The files contains method headers which look like this: > > > final @Override > @ForceInline > long longToElementBits(... > > @ForceInline > static long toIntegralChecked(... > > @ForceInline > @Override final > ByteVector dummyVector(... > > > My personal opinion is that these should have been written like this: > > > @Override > @ForceInline > final long longToElementBits(... > > @ForceInline > static long toIntegralChecked(... > > @ForceInline > @Override > final ByteVector dummyVector(... > > > or possibly > > > > @Override @ForceInline > final long longToElementBits(... > > @ForceInline > static long toIntegralChecked(... > > @ForceInline @Override > final ByteVector dummyVector(... > > > If you want me to make that change as well as part of the fix, let me know. > > Furthermore, I don't know how much the code in mainline differs from the code in the Panama branches. If the discrepancy is large, you might want to run `bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and `bash bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches. > > ------------- > > Commit messages: > - 8277015: Use blessed modifier order in Panama code > > Changes: https://git.openjdk.java.net/jdk/pull/6355/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6355&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8277015 > Stats: 21 lines in 13 files changed: 0 ins; 0 del; 21 mod > Patch: https://git.openjdk.java.net/jdk/pull/6355.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/6355/head:pull/6355 > > PR: https://git.openjdk.java.net/jdk/pull/6355 From maurizio.cimadamore at oracle.com Thu Nov 11 15:26:26 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Nov 2021 15:26:26 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> <60c217bc-2fa8-c1f9-080e-fe3342ce47b2@oracle.com> Message-ID: I'm not sure I follow your point entirely. But yes, if you do a bindTo(this), then using an implicit scope is not very useful as long as the scope is reachable from `this`. We might be able to refine the implementation and improve this in the future, but for now I think that's something we have to live with. Thanks Maurizio On 11/11/2021 14:41, R?my Maucherat wrote: > Unless I missed something the API has a side effect with upcalls. I > understand after reading the javadoc where the suggestion comes from, > as it makes memory management very much like Java. This is of course > excellent. However, I use upcalls (as you know) and many of them are > bound to an instance (since this makes state tracking very very nice). > This however creates a reference that never goes away and an implicit > scope is never going to get GCed and closed (I saw that with visualvm) > and memory leaks. Initially I was planning to use a static Map State> for my state (OpenSSL allows passing references and getting > them in callbacks, but this is a lot handier in C and doesn't make a > lot of sense in Java), then I found MethodHandle.bindTo actually > worked and this is quite magical. > > So with that in mind, what is the recommendation ? Should the API > provide a way to remove the MethodHandle upcall ? Or should I avoid > using bindTo instead ? From maurizio.cimadamore at oracle.com Thu Nov 11 17:01:08 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Nov 2021 17:01:08 +0000 Subject: OpenSSL and panama-foreign In-Reply-To: References: <510f22de-a49e-df17-2e02-029a15c75ee7@oracle.com> <048afb97-dd2d-0221-1eff-d207fe816a7a@oracle.com> <60c217bc-2fa8-c1f9-080e-fe3342ce47b2@oracle.com> Message-ID: Just to be clear - can you see the cleaner working with your current implementation? After thinking about your use case some more, I'm not convinced that what you do is enough to prevent reachability issues. That is - the MH is kept alive by the CLinker runtime (at least until the scope is closed). But, with `bindTo`, the MH also keeps `this` alive. It follows that, unless the scope is closed, `this` will never become unreachable. Which seems to defeat the point of registering `this` against a cleaner on construction? Maurizio P.S. I did some experiments with your panama-foreign branch, and it seems like, when running the `ab` test, all calls to the cleaner action comes from the shutdown method, which invokes the cleaner's cloneable manually. If I remove the call to Cleanable::clean in shutdown, then I don't see any call to the cleanup action being executed for the entire duration of the benchmark. On 11/11/2021 15:26, Maurizio Cimadamore wrote: > I'm not sure I follow your point entirely. > > But yes, if you do a bindTo(this), then using an implicit scope is not > very useful as long as the scope is reachable from `this`. > > We might be able to refine the implementation and improve this in the > future, but for now I think that's something we have to live with. > > Thanks > Maurizio > > > On 11/11/2021 14:41, R?my Maucherat wrote: >> Unless I missed something the API has a side effect with upcalls. I >> understand after reading the javadoc where the suggestion comes from, >> as it makes memory management very much like Java. This is of course >> excellent. However, I use upcalls (as you know) and many of them are >> bound to an instance (since this makes state tracking very very nice). >> This however creates a reference that never goes away and an implicit >> scope is never going to get GCed and closed (I saw that with visualvm) >> and memory leaks. Initially I was planning to use a static Map> State> for my state (OpenSSL allows passing references and getting >> them in callbacks, but this is a lot handier in C and doesn't make a >> lot of sense in Java), then I found MethodHandle.bindTo actually >> worked and this is quite magical. >> >> So with that in mind, what is the recommendation ? Should the API >> provide a way to remove the MethodHandle upcall ? Or should I avoid >> using bindTo instead ? From ngasson at openjdk.java.net Fri Nov 12 08:27:13 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 12 Nov 2021 08:27:13 GMT Subject: [foreign-memaccess+abi] RFR: 8276987: Optimized upcall stub should be printed with -XX:+PrintStubCode Message-ID: That would allow it to be found by JMH's profasm which uses `-XX:+PrintStubCode` to collect the addresses of stubs. Note that JMH at the moment can't actually parse the stubs printed by `trace_new_stub` (because they have a "Decoding ..." prefix and don't include the end address), but that can be fixed on the JMH side. ------------- Commit messages: - 8276987: Optimized upcall stub should be printed with -XX:+PrintStubCode Changes: https://git.openjdk.java.net/panama-foreign/pull/611/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276987 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/611.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/611/head:pull/611 PR: https://git.openjdk.java.net/panama-foreign/pull/611 From duke at openjdk.java.net Fri Nov 12 11:06:35 2021 From: duke at openjdk.java.net (duke) Date: Fri, 12 Nov 2021 11:06:35 GMT Subject: git: openjdk/panama-foreign: master: 94 new changesets Message-ID: <1e347376-91f2-45bc-87c1-801d6b9e7a63@openjdk.org> Changeset: 0616d868 Author: Magnus Ihse Bursie Date: 2021-11-05 12:05:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0616d868c7cd5010f017b315fa1cf6cc1617ce29 8276635: Use blessed modifier order in compiler code Reviewed-by: darcy ! src/java.compiler/share/classes/javax/tools/Diagnostic.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java Changeset: b9331360 Author: Magnus Ihse Bursie Date: 2021-11-05 12:06:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b9331360f50afe5b4549d7003d4932ebc54a3c71 8276641: Use blessed modifier order in jshell Reviewed-by: iris ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/AnsiWriter.java ! src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/WindowsAnsiWriter.java ! src/jdk.jshell/share/classes/jdk/jshell/Key.java ! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java ! src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java Changeset: 7023b3f8 Author: Magnus Ihse Bursie Date: 2021-11-05 12:07:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7023b3f8a120dda97bc27fdf130c05c1bd7a730b 8276628: Use blessed modifier order in serviceability code Reviewed-by: dholmes, lmesnik, cjplummer ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanServerDelegateImpl.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MXBeanProxy.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/HashedPasswordManager.java ! src/java.management/share/classes/javax/management/MBeanServerFactory.java ! src/java.management/share/classes/javax/management/ObjectName.java ! src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/java.management/share/classes/javax/management/timer/Timer.java ! src/java.management/share/classes/sun/management/ClassLoadingImpl.java ! src/java.management/share/classes/sun/management/NotificationEmitterSupport.java ! src/java.management/share/classes/sun/management/VMManagementImpl.java ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/aarch64/LinuxAARCH64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1MonitoringSupport.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionSetBase.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenCollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeapRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZAttachedArrayForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingEntry.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobals.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobalsForVMStructs.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGranuleMapForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGranuleMapForPageTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPage.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPageAllocator.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPageTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZRelocate.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZVirtualMemory.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DataLayout.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DefaultMetadataVisitor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ParametersTypeData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/SpeculativeTrapData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Node.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/InstanceConstructor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/tree/CTypeTreeNodeAdapter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java ! src/jdk.jdi/share/classes/com/sun/jdi/Bootstrap.java ! src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/Packet.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/PrimitiveValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TargetVM.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TypeComponentImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java ! src/jdk.management.agent/share/classes/sun/management/jdp/JdpJmxPacket.java ! src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java ! src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectorExtImpl.java ! src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java Changeset: c393ee8f Author: Magnus Ihse Bursie Date: 2021-11-05 14:09:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c393ee8f598850379266bdba1f55af94744dbad1 8276632: Use blessed modifier order in security-libs code Reviewed-by: mullan ! src/java.security.jgss/share/classes/sun/security/jgss/ProviderList.java ! src/java.security.jgss/share/classes/sun/security/jgss/TokenTracker.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/java.smartcardio/share/classes/javax/smartcardio/CardNotPresentException.java ! src/java.smartcardio/share/classes/javax/smartcardio/CardPermission.java ! src/java.smartcardio/share/classes/javax/smartcardio/TerminalFactory.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/ChannelImpl.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/PCSC.java ! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java ! src/java.smartcardio/windows/classes/sun/security/smartcardio/PlatformPCSC.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Constants.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKey.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CRSACipher.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CSignature.java Changeset: a74a839a Author: Vladimir Kozlov Date: 2021-11-05 16:07:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a74a839af02446d322d77c6e546e652ec6ad5d73 8276571: C2: pass compilation options as structure Reviewed-by: shade, chagedorn ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: 92d21763 Author: Daniel D. Daugherty Date: 2021-11-05 17:04:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92d2176362954a7093894057748056610eeafe4b 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 Reviewed-by: stuefe, gziemski ! src/hotspot/os/bsd/decoder_machO.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/share/runtime/os.cpp ! test/hotspot/gtest/runtime/test_os.cpp Changeset: b01f1073 Author: Brian Burkhalter Date: 2021-11-05 17:25:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b01f1073f9691c40fc15b7ed67ae2e019ff729ea 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error Reviewed-by: lancea ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: a4724332 Author: Andrew John Hughes Date: 2021-11-05 21:05:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a4724332098cd8bff44ee27e9190fd28fa5c1865 8276572: Fake libsyslookup.so library causes tooling issues Reviewed-by: shade, mcimadamore ! src/jdk.incubator.foreign/share/native/libsyslookup/syslookup.c Changeset: 0e0dd33f Author: Kim Barrett Date: 2021-11-05 21:20:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e0dd33fff9922a086968cfa6ccd27727f979c83 8276129: PretouchTask should page-align the chunk size Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/shared/pretouchTask.cpp Changeset: 59c3dcc7 Author: Magnus Ihse Bursie Date: 2021-11-05 21:21:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59c3dcc761ac7a9eab1517743cbb77e5526ca6f3 8276746: Add section on reproducible builds in building.md Reviewed-by: erikj, sgehwolf, aleonard ! doc/building.html ! doc/building.md Changeset: ed7ecca4 Author: Hamlin Li Date: 2021-11-05 23:24:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ed7ecca401e5f4c3c07dc98e05a21396c6cdf594 8254739: G1: Optimize evacuation failure for regions with few failed objects Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp ! src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp Changeset: c7095b20 Author: Anirvan Sarkar Committer: Joe Wang Date: 2021-11-06 00:41:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7095b20d956e154d9863a7928d26285f1a0a0ac 8276207: Properties.loadFromXML/storeToXML works incorrectly for supplementary characters Reviewed-by: joehw ! src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java ! src/java.base/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java ! test/jdk/java/util/Properties/LoadAndStoreXML.java Changeset: 2653cfbf Author: Jaikiran Pai Date: 2021-11-06 03:36:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2653cfbf0f316183ea23dd234896b44f7dd6eae0 8276688: Remove JLinkReproducibleXXXTest from ProblemList.txt Reviewed-by: alanb, mchung ! test/jdk/ProblemList.txt Changeset: 88491549 Author: Ioi Lam Date: 2021-11-07 21:38:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/884915496f7bfe754279f1644603131c64f192b3 8275846: read_base_archive_name() could read past the end of buffer Reviewed-by: ccheung, stuefe ! src/hotspot/share/cds/filemap.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java Changeset: 44047f84 Author: Yi Yang Date: 2021-11-08 02:18:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/44047f849fad157dac5df788aa5a2c1838e4aaf7 8274328: C2: Redundant CFG edges fixup in block ordering Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/block.cpp ! src/hotspot/share/opto/block.hpp Changeset: 3934fe54 Author: Nick Gasson Date: 2021-11-08 06:40:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3934fe54b4c3e51add6d3fe1f145e5aebfe3b2fc 8275847: Scheduling fails with "too many D-U pinch points" on small method Reviewed-by: thartmann, kvn ! src/hotspot/cpu/x86/vmreg_x86.hpp ! src/hotspot/share/opto/buildOopMap.cpp ! src/hotspot/share/opto/output.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestScheduleSmallMethod.java Changeset: fc0fe256 Author: Christian Stein Committer: Aleksey Shipilev Date: 2021-11-08 08:09:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc0fe256793b33430c1247e0c091150a091da3c4 8273235: tools/launcher/HelpFlagsTest.java Fails on Windows 32bit Reviewed-by: shade ! test/jdk/tools/launcher/HelpFlagsTest.java Changeset: d8b0dee6 Author: Ludvig Janiuk Committer: Claes Redestad Date: 2021-11-08 09:44:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8b0dee65e7e074d81eecf451542f79747ea7c78 8276239: Better tables in java.util.random package summary Reviewed-by: jlaskey ! src/java.base/share/classes/java/util/random/package-info.java Changeset: 0395e4ef Author: Hannes Walln?fer Date: 2021-11-08 11:35:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0395e4ef8ced8385cc2c9b3bea4c6f4490c62d2b 8276768: Snippet copy feature should use button instead of link Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java Changeset: 54481394 Author: Christian Hagedorn Date: 2021-11-08 12:47:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/54481394a3b7d36b2326e22e4aa910a3e8041b5c 8271056: C2: "assert(no_dead_loop) failed: dead loop detected" due to cmoving identity Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/cfgnode.cpp + test/hotspot/jtreg/compiler/c2/TestDeadDataLoopCmoveIdentity.java Changeset: ff6863c9 Author: Thomas Schatzl Date: 2021-11-08 12:59:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff6863c98dbd15c4f3920402eb0991727d1a380c 8276540: Howl Full CardSet container iteration marks too many cards Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp Changeset: 4c14eddf Author: Jan Lahoda Date: 2021-11-08 13:19:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c14eddf41f1d9984417dc5ac6aba6f268b31029 8274734: the method jdk.jshell.SourceCodeAnalysis documentation not working Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java + test/langtools/jdk/jshell/MultipleDocumentationTest.java Changeset: fa754b8f Author: Jan Lahoda Date: 2021-11-08 13:20:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa754b8ffda0ae16cda03d896260870ff8fb6ae9 8276149: jshell throws EOF error when throwing exception inside switch expression Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/langtools/jdk/jshell/CompletenessTest.java Changeset: 0c2d00bf Author: Jan Lahoda Date: 2021-11-08 13:21:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0c2d00bff7b96cca53820aadfdaf09c840a2a33a 8275097: Wrong span of the 'default' tag Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/parser/JavacParserTest.java ! test/langtools/tools/javac/patterns/SwitchErrors.out Changeset: cc2cac13 Author: Petr Portnov Committer: Roger Riggs Date: 2021-11-08 13:22:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cc2cac130cc28730a30d2e1d76bcb6ec8bc0b580 8274686: java.util.UUID#hashCode() should use Long.hashCode() Reviewed-by: rriggs ! src/java.base/share/classes/java/util/UUID.java Changeset: 71c4b195 Author: Andy Herrick Date: 2021-11-08 13:45:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/71c4b195178029f5414fa45d2c5ac70a1d2536e5 8276562: Fix to JDK-8263155 left out the help text changes Reviewed-by: asemenyuk, almatvee ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties Changeset: c815c5cb Author: Denghui Dong Date: 2021-11-08 14:30:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c815c5cbbb0b6a2aebd0a38cb930c74bd665d082 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) Reviewed-by: dholmes, coleenp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_Runtime1_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: ea23e733 Author: Daniel D. Daugherty Date: 2021-11-08 14:45:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea23e7333e03abb4aca3e9f3854bab418a4b70e2 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes Reviewed-by: coleenp, sspitsyn, dholmes, rehn ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEventController.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 7320b77b Author: Thomas Schatzl Date: 2021-11-08 15:00:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7320b77b3e451932ee8befa7af4b80593725761e 8276548: Use range based visitor for Howl-Full cards Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp Changeset: 75adf54b Author: Aleksey Shipilev Date: 2021-11-08 15:35:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/75adf54bdcc5e06fb8e8ca499a2f326d70b65f76 8276306: jdk/jshell/CustomInputToolBuilder.java fails intermittently on storage acquisition Reviewed-by: jlahoda ! test/langtools/jdk/jshell/CustomInputToolBuilder.java Changeset: 7e73bca0 Author: Roger Riggs Date: 2021-11-08 16:39:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e73bca0b7a34af9fb73780491951539815651b4 8276408: Deprecate Runtime.exec methods with a single string command line argument Reviewed-by: alanb ! src/java.base/share/classes/java/lang/Runtime.java ! test/jdk/java/lang/ProcessBuilder/Zombies.java ! test/jdk/java/lang/RuntimeTests/exec/BadEnvp.java ! test/jdk/java/lang/RuntimeTests/exec/ExecWithDir.java ! test/jdk/java/lang/RuntimeTests/exec/SetCwd.java Changeset: e383d263 Author: Jonathan Gibbons Date: 2021-11-08 19:13:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e383d263610c7b4d4be2dce599a9043b8f76cd64 8275199: Bogus warning generated for serializable records Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java = test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list Changeset: 905e3e88 Author: Eamonn McManus Date: 2021-11-08 19:57:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/905e3e88137d46f90de7034e9fc324e97af873a6 8231490: Ugly racy writes to ZipUtils.defaultBuf Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/Inflater.java Changeset: 14d66bd4 Author: Andrew Leonard Date: 2021-11-08 20:37:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14d66bd438dfa1feeafaca39be8f79a91e2968e9 8276654: element-list order is non deterministic Reviewed-by: ihse ! make/modules/jdk.javadoc/Gendata.gmk Changeset: a7dedb5f Author: Joe Darcy Date: 2021-11-08 22:19:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a7dedb5f4761a7d0bc4db658d96d369b13b80620 8276772: Refine javax.lang.model docs Reviewed-by: iris, vromero ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java ! src/java.compiler/share/classes/javax/lang/model/element/RecordComponentElement.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/type/NoType.java ! src/java.compiler/share/classes/javax/lang/model/type/NullType.java ! src/java.compiler/share/classes/javax/lang/model/type/PrimitiveType.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 38e6d5d6 Author: Bradford Wetmore Date: 2021-11-09 01:11:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38e6d5d6ed967f68e6ac1bfaa285efa16577c790 8276677: Malformed Javadoc inline tags in JDK source in javax/net/ssl Reviewed-by: jnimeh ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java Changeset: 8747882e Author: Ioi Lam Date: 2021-11-09 07:18:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8747882e4cb3af58062923bf830f9de877bdb03d 8276790: Rename GenericCDSFileMapHeader::_base_archive_path_offset Reviewed-by: dholmes, ccheung ! src/hotspot/share/cds/cdsConstants.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/include/cds.h ! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java Changeset: 945f4085 Author: Stefan Johansson Date: 2021-11-09 11:11:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/945f4085e5c51f37c2048bb221a1521895ba28c6 8276098: Do precise BOT updates in G1 evacuation phase Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Allocator.hpp ! src/hotspot/share/gc/g1/g1Allocator.inline.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/shared/plab.hpp Changeset: 5c7f77c8 Author: Thomas Schatzl Date: 2021-11-09 13:07:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5c7f77c82404976a6ca1d54b40f1969eac10d63b 8276850: Remove outdated comment in HeapRegionManager::par_iterate Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/heapRegionManager.cpp Changeset: 4bd5bfd8 Author: Thomas Stuefe Date: 2021-11-09 14:12:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4bd5bfd8e2624715ebfa6e4c49172361389fbc98 8276731: Metaspace chunks are uncommitted twice Reviewed-by: shade, coleenp ! src/hotspot/share/memory/metaspace/chunkManager.cpp Changeset: e1985947 Author: Masanori Yano Committer: Alan Bateman Date: 2021-11-09 14:28:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e198594753b0b0653256923586c7f4ec9e3cfac3 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Reviewed-by: mchung, alanb ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! test/jdk/java/lang/module/VersionTest.java Changeset: c27afb31 Author: Weijun Wang Date: 2021-11-09 14:46:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c27afb313b77d19e7ace7101c6f21aa5b2c56505 8276863: Remove test/jdk/sun/security/ec/ECDSAJavaVerify.java Reviewed-by: ascarpino - test/jdk/sun/security/ec/ECDSAJavaVerify.java Changeset: f65db88b Author: Yasumasa Suenaga Date: 2021-11-09 14:54:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f65db88b74911e5896d2ff536c4ac97e7f62d98b 8276841: Add support for Visual Studio 2022 Reviewed-by: erikj, ihse ! make/autoconf/toolchain_microsoft.m4 Changeset: e35abe32 Author: Hannes Walln?fer Date: 2021-11-09 15:05:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e35abe3235ab38985a19545e76c58260ec97c718 8256208: Javadoc's generated overview does not show classes of unnamed package Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java = test/langtools/jdk/javadoc/doclet/testUnnamedPackage/src1/pkg/D.java + test/langtools/jdk/javadoc/doclet/testUnnamedPackage/src1/pkg/package.html Changeset: 93692ea0 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-09 16:58:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/93692ea0a9bc437309b808f511c771a79dcdfb9a 8274395: Use enhanced-for instead of plain 'for' in jdk.internal.jvmstat Reviewed-by: cjplummer, amenkov, sspitsyn ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java Changeset: daf77ebf Author: Leo Korinth Date: 2021-11-09 17:50:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/daf77ebfc4ca6d537ef55acbd62b908b5575ad08 8276337: Use override specifier in HeapDumper Reviewed-by: stuefe, dholmes ! src/hotspot/share/services/heapDumper.cpp Changeset: dde959df Author: Brian Burkhalter Date: 2021-11-09 19:17:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dde959dfcef01897fdf51f820d414402e6309b8d 8276808: java/nio/channels/Channels/TransferTo.java timed out Reviewed-by: lancea, shade ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: a60e9125 Author: Pankaj Bansal Date: 2021-11-09 20:10:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a60e91259ba83d2a525b612b2c7a1fd7934b88a2 8198626: java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java Changeset: 055de6f5 Author: Hannes Walln?fer Date: 2021-11-09 20:11:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/055de6f566208b168818be1dc3ad29cdb9caa1cf 8223358: Incorrect HTML structure in annotation pages Reviewed-by: jjg + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeMemberWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeMemberWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeOptionalMemberWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AbstractMemberBuilder.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeMemberBuilder.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/pkg/AnnotationType.java Changeset: f9024d06 Author: Hannes Walln?fer Date: 2021-11-09 20:17:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f9024d0606e39863b590f0d7c949d569f8bf8abd 8230130: javadoc search result dialog shows cut off headers for long results Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Changeset: d7012fbd Author: Roger Riggs Date: 2021-11-09 20:43:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7012fbd604fc1a54a2d7364a6ca4a32f47ffc7c 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary Reviewed-by: alanb - test/jdk/java/lang/RuntimeTests/exec/ExecWithDir.java Changeset: 06992208 Author: Rickard B?ckman Date: 2021-11-09 21:38:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0699220830a457959b784b35af125b70f43fa3b0 8268882: C2: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Reviewed-by: neliasso, chagedorn, kvn ! src/hotspot/share/opto/postaloc.cpp Changeset: c8b0ee6b Author: Hamlin Li Date: 2021-11-10 01:12:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c8b0ee6b8a0c1bca8f8357e786f24c8cb6dd7310 8276833: G1: Make G1EvacFailureRegions::par_iterate const Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp Changeset: c1e41fe3 Author: Hamlin Li Date: 2021-11-10 01:13:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1e41fe38bbbae12e1f73d2cd63c7afffc19475b 8276842: G1: Only calculate size in bytes from words when needed Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailure.cpp Changeset: 8822d41f Author: Jamil Nimeh Date: 2021-11-10 01:24:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8822d41fdcc2c2d568badd72635dc587d21dbd63 8274736: Concurrent read/close of SSLSockets causes SSLSessions to be invalidated unnecessarily Reviewed-by: xuelei, wetmore ! src/java.base/share/classes/sun/security/ssl/TransportContext.java ! test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java + test/jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java Changeset: e91e9d85 Author: Hamlin Li Date: 2021-11-10 01:26:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e91e9d853272ea8f5ce490f2f0c971fd40795d74 8276721: G1: Refine G1EvacFailureObjectsSet::iterate Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp Changeset: 403f3185 Author: Anirvan Sarkar Committer: Christoph Langer Date: 2021-11-10 05:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/403f3185f0988dcf6ef4e857d6659533bfa2943f 8276854: Windows GHA builds fail due to broken Cygwin Reviewed-by: clanger ! .github/workflows/submit.yml Changeset: fd0a25e6 Author: Aleksey Shipilev Date: 2021-11-10 07:59:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd0a25e62b2c8abc3a419c2e80abbcf11c9e882f 8276805: java/awt/print/PrinterJob/CheckPrivilege.java fails due to disabled SecurityManager Reviewed-by: serb, aivanov ! test/jdk/java/awt/print/PrinterJob/CheckPrivilege.java Changeset: e01d6d00 Author: Prasanta Sadhukhan Date: 2021-11-10 08:34:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e01d6d00bc4ab5ca0d38f8894a78e6d911e0fe93 8276679: Malformed Javadoc inline tags in JDK source in javax/swing Reviewed-by: aivanov, pbansal ! src/java.desktop/share/classes/javax/swing/JTree.java ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java ! src/java.desktop/share/classes/javax/swing/event/HyperlinkEvent.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java Changeset: 0f463a7b Author: Aleksey Shipilev Date: 2021-11-10 09:50:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f463a7bf73791eda9404882ff63daf9040399bb 8276845: (fs) java/nio/file/spi/SetDefaultProvider.java fails on x86_32 Reviewed-by: alanb ! test/jdk/java/nio/file/spi/TestProvider.java Changeset: a3f710ef Author: Aleksey Shipilev Date: 2021-11-10 10:45:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a3f710efbe7dcef18477a96fd306bec19f181f8b 8276215: Intrinsics matchers should handle native method flags better Reviewed-by: dholmes, kvn ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp Changeset: a0b84453 Author: Aleksey Shipilev Date: 2021-11-10 11:27:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a0b84453b087ff368a32b93729c5b30fda22ed48 8276846: JDK-8273416 is incomplete for UseSSE=1 Reviewed-by: neliasso, kvn ! src/hotspot/cpu/x86/x86_32.ad Changeset: 0f23c6a9 Author: Sergey Tsypanov Committer: Claes Redestad Date: 2021-11-10 12:46:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f23c6a9feb3657eb20ff5988a9e2ffca2108af1 8276926: Use String.valueOf() when initializing File.separator and File.pathSeparator Reviewed-by: redestad, jlaskey ! src/java.base/share/classes/java/io/File.java Changeset: 55b36c6f Author: Harold Seigel Date: 2021-11-10 13:11:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/55b36c6f3bb7eb066daaf41f9eba46633afedf08 8276825: hotspot/runtime/SelectionResolution test errors Reviewed-by: dholmes, shade ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/ClassBuilder.java ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/Clazz.java ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/TestBuilder.java Changeset: 38ec3a16 Author: Yasumasa Suenaga Date: 2021-11-10 14:33:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38ec3a16d722d740d0b2128c6f6c2d1eab7a7c08 8276672: Cannot build hsdis on WSL Co-authored-by: Magnus Ihse Bursie Co-authored-by: Yasumasa Suenaga Reviewed-by: ihse, erikj ! make/Hsdis.gmk Changeset: f561d3c1 Author: Aleksey Shipilev Date: 2021-11-10 14:41:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f561d3c1942ce901fa77c907839032f76feb6998 8276864: Update boot JDKs to 17.0.1 in GHA Reviewed-by: erikj, ihse ! make/conf/test-dependencies Changeset: ce3ed65a Author: Jonathan Gibbons Date: 2021-11-10 15:24:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce3ed65ac3411a533052a8c01231f7e540803afb 8273154: Provide a JavadocTester method for non-overlapping, unordered output matching Reviewed-by: prappo ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java + test/langtools/jdk/javadoc/testJavadocTester/TestJavadocTester.java Changeset: a5c160c7 Author: Weijun Wang Date: 2021-11-10 19:35:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5c160c711a3f66db18c75973f4efdea63332863 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs Reviewed-by: mullan ! src/java.base/share/classes/javax/security/auth/Subject.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java ! test/jdk/com/sun/security/sasl/gsskerb/AuthOnly.java ! test/jdk/com/sun/security/sasl/gsskerb/ConfSecurityLayer.java ! test/jdk/com/sun/security/sasl/gsskerb/NoSecurityLayer.java ! test/jdk/java/security/AccessController/PreserveCombiner.java + test/jdk/javax/security/auth/Subject/CurrentSubject.java ! test/jdk/javax/security/auth/Subject/DoAs.java + test/jdk/javax/security/auth/Subject/Exceptions.java + test/jdk/javax/security/auth/Subject/FromACC.java ! test/jdk/javax/security/auth/Subject/Synch.java ! test/jdk/sun/security/krb5/KrbCredSubKey.java ! test/jdk/sun/security/krb5/ServiceCredsCombination.java ! test/jdk/sun/security/krb5/auto/Context.java ! test/jdk/sun/security/krb5/auto/HttpNegotiateServer.java ! test/jdk/sun/security/krb5/auto/LongLife.java Changeset: 67c2714b Author: Coleen Phillimore Date: 2021-11-10 19:45:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67c2714ba2c9658e07153a6f50391c896e4caebc 8276889: Improve compatibility discussion in instanceKlass.cpp Reviewed-by: hseigel ! src/hotspot/share/oops/instanceKlass.cpp Changeset: 2374abda Author: Alisen Chung Committer: Alexey Ivanov Date: 2021-11-10 20:08:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2374abda19213d615a72c83f584ea61d5bbba4a3 8276678: Malformed Javadoc inline tags in JDK source in com/sun/beans/decoder/DocumentHandler.java Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/com/sun/beans/decoder/DocumentHandler.java Changeset: df02daa6 Author: Ioi Lam Date: 2021-11-10 20:22:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/df02daa6f9df801a7e0b6203fd6411d8a62bb277 8269986: Remove +3 from Symbol::identity_hash() Reviewed-by: coleenp ! src/hotspot/share/oops/symbol.hpp Changeset: 0c409cac Author: Naoto Sato Date: 2021-11-10 20:52:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0c409cac789f1b1d21e09a65db36bb6c72c569db 8276186: Require getAvailableLocales() methods to include Locale.ROOT Reviewed-by: prappo, smarks, iris ! src/java.base/share/classes/java/text/BreakIterator.java ! src/java.base/share/classes/java/text/Collator.java ! src/java.base/share/classes/java/text/DateFormat.java ! src/java.base/share/classes/java/text/DateFormatSymbols.java ! src/java.base/share/classes/java/text/DecimalFormatSymbols.java ! src/java.base/share/classes/java/text/NumberFormat.java ! src/java.base/share/classes/java/time/format/DecimalStyle.java ! src/java.base/share/classes/java/util/Calendar.java ! src/java.base/share/classes/java/util/Locale.java + test/jdk/java/util/Locale/RequiredAvailableLocalesTest.java Changeset: bce35ac1 Author: Naoto Sato Date: 2021-11-10 20:53:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bce35ac1d6c4115148468a3240ad459074e0b79e 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893 Reviewed-by: lancea, iris, bpb, scolebourne, rriggs ! src/java.base/share/classes/java/time/OffsetDateTime.java ! src/java.base/share/classes/java/time/ZonedDateTime.java Changeset: 73e6d7d7 Author: Zhengyu Gu Date: 2021-11-11 00:14:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/73e6d7d74d2ddd27f11775944c6fc4fb5268106d 8276801: gc/stress/CriticalNativeStress.java fails intermittently with Shenandoah Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp Changeset: e27a67a9 Author: Jesper Wilhelmsson Date: 2021-11-11 01:14:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e27a67a91647e584411a9ef57c0a028ab37af19b 8276930: Update ProblemList Reviewed-by: kevinw, dholmes ! test/jdk/ProblemList.txt Changeset: ad3be04d Author: Yoshiki Sato Committer: Naoto Sato Date: 2021-11-11 01:39:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ad3be04d2ac84836e393d696ff03ddfe72779094 8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766 Reviewed-by: naoto, coffeys ! src/java.base/share/classes/sun/util/resources/TimeZoneNames.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_de.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_es.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_fr.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_it.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ja.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ko.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_pt_BR.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_sv.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_CN.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_TW.java Changeset: 08e0fd67 Author: Hamlin Li Date: 2021-11-11 05:52:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/08e0fd6757ef15b71df0e86afd01211a6e48bd09 8276835: G1: make G1EvacFailureObjectsSet::record inline Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: 91bb0d65 Author: Aleksey Shipilev Date: 2021-11-11 07:07:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/91bb0d658bce010e74b248b56f0fa5b8a79e8802 8276796: gc/TestSystemGC.java large pages subtest fails with ZGC Reviewed-by: pliden, stefank ! test/hotspot/jtreg/gc/TestSystemGC.java Changeset: 7a140af2 Author: Christian Hagedorn Date: 2021-11-11 08:03:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a140af25362556ebe86147dcd74413e0044edc0 8276546: [IR Framework] Whitelist and ignore CompileThreshold Reviewed-by: kvn, neliasso ! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompileThreshold.java Changeset: 9862cd07 Author: Hannes Walln?fer Date: 2021-11-11 09:13:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9862cd07c162fcc9cd5cbdd0aab564f446f9256c 8275786: New javadoc option to add script files to generated documentation Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/langtools/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java + test/langtools/jdk/javadoc/doclet/testOptions/additional-script-1.js + test/langtools/jdk/javadoc/doclet/testOptions/additional-script-2.js ! test/langtools/jdk/javadoc/tool/CheckManPageOptions.java Changeset: aea09677 Author: casparcwang Committer: Hui Shi Date: 2021-11-11 10:39:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aea096770e74b9c0e1556467705ffdd6cf843d9d 8275854: C2: assert(stride_con != 0) failed: missed some peephole opt Co-authored-by: Roland Westrelin Reviewed-by: thartmann, roland, kvn ! src/hotspot/share/opto/ifnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestLoopEndNodeEliminate.java Changeset: c29cab8a Author: Tobias Hartmann Date: 2021-11-11 13:09:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c29cab8ab475055e02e4300f212907ff2db955ab 8276112: Inconsistent scalar replacement debug info at safepoints Reviewed-by: kvn, chagedorn ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/macro.hpp ! test/hotspot/jtreg/compiler/eliminateAutobox/TestIdentityWithEliminateBoxInDebugInfo.java + test/hotspot/jtreg/compiler/eliminateAutobox/TestSafepointDebugInfo.java Changeset: 2ca4ff87 Author: Aleksei Efimov Date: 2021-11-11 14:33:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ca4ff87b7c31d56542bbdcea70e828be33f4e97 8244202: Implementation of JEP 418: Internet-Address Resolution SPI Co-authored-by: Chris Hegarty Co-authored-by: Daniel Fuchs Co-authored-by: Alan Bateman Reviewed-by: dfuchs, alanb, michaelm, chegar ! src/java.base/share/classes/java/lang/RuntimePermission.java ! src/java.base/share/classes/java/net/Inet4AddressImpl.java ! src/java.base/share/classes/java/net/Inet6AddressImpl.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/InetAddressImpl.java ! src/java.base/share/classes/java/net/doc-files/net-properties.html + src/java.base/share/classes/java/net/spi/InetAddressResolver.java + src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java ! src/java.base/share/classes/java/net/spi/package-info.java ! src/java.base/share/classes/jdk/internal/access/JavaNetInetAddressAccess.java ! src/java.base/share/classes/module-info.java + src/java.base/share/classes/sun/net/ResolverProviderConfiguration.java ! src/java.base/share/native/libnet/InetAddress.c ! src/java.base/share/native/libnet/net_util.c ! src/java.base/share/native/libnet/net_util.h ! src/java.base/unix/native/libnet/Inet4AddressImpl.c ! src/java.base/unix/native/libnet/Inet6AddressImpl.c ! src/java.base/windows/native/libnet/Inet6AddressImpl.c + test/jdk/java/net/spi/InetAddressResolverProvider/AddressesCachingTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/BootstrapResolverUsageTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/BuiltInResolverTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/EmptyResultsStreamTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ForeverCache.props + test/jdk/java/net/spi/InetAddressResolverProvider/InetAddressUsageInGetProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/LookupPolicyMappingTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/LookupPolicyOfTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/NeverCache.props + test/jdk/java/net/spi/InetAddressResolverProvider/ProviderGetExceptionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ResolutionWithExceptionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ResolvePermissionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ReverseLookupDelegationTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/RuntimePermissionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/addresses.txt + test/jdk/java/net/spi/InetAddressResolverProvider/lib/test.library/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/lib/test.library/testlib/ResolutionRegistry.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/bootstrapUsage/bootstrap.usage.provider/impl/WithBootstrapResolverUsageProvider.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/bootstrapUsage/bootstrap.usage.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/delegating/delegating.provider/impl/DelegatingProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/delegating/delegating.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/empty/empty.results.provider/impl/EmptyResultsProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/empty/empty.results.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/faulty/faulty.provider/impl/FaultyResolverProviderGetImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/faulty/faulty.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/simple/simple.provider/impl/SimpleResolverProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/simple/simple.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/throwing/throwing.lookups.provider/impl/ThrowingLookupsProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/throwing/throwing.lookups.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/ClasspathProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/ClasspathResolverProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/META-INF/services/java.net.spi.InetAddressResolverProvider + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/addresses.txt + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/module/ModularProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/module/addresses.txt ! test/lib/jdk/test/lib/net/IPSupport.java Changeset: 5e98f993 Author: Ludvig Janiuk Committer: Alexey Ivanov Date: 2021-11-11 16:46:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e98f993b3cd68bb8564ea904f322235f55c4a7c 8276800: Fix table headers in NumericShaper.html Reviewed-by: naoto, aivanov ! src/java.desktop/share/classes/java/awt/font/NumericShaper.java Changeset: 6f35eede Author: Alexander Zvegintsev Date: 2021-11-11 16:53:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f35eede4576b6252544f553c3651312b024e7ea 8079267: [TEST_BUG] Test java/awt/Frame/MiscUndecorated/RepaintTest.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Frame/MiscUndecorated/RepaintTest.java Changeset: 8aae88b0 Author: Alan Bateman Date: 2021-11-11 19:07:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8aae88b0fc4acb76ef140f120712403cf4b04a46 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out" Reviewed-by: dfuchs ! test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java Changeset: b0d7a9da Author: Lance Andersen Date: 2021-11-11 19:09:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b0d7a9daa6ceb1959bc701043fe3f0397d2ba6f7 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp Reviewed-by: alanb ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: 0ca0acf6 Author: Claes Redestad Date: 2021-11-11 20:36:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ca0acf63cb5cec4c62a9948956a04822d6f74a5 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: 3445e50b Author: David Holmes Date: 2021-11-11 22:10:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3445e50bd573857660908a964886f94714315f4c 8276265: jcmd man page is outdated Reviewed-by: stuefe, cjplummer ! src/jdk.jcmd/share/man/jcmd.1 Changeset: 6954b98f Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-11 22:23:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6954b98f8faf29b6c2d13687a7a94e83302bdd85 8186670: Implement _onSpinWait() intrinsic for AArch64 Reviewed-by: phh, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp + src/hotspot/cpu/aarch64/spin_wait_aarch64.hpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64.java + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitNoneAArch64.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWait.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitProducerConsumer.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitSharedCounter.java Changeset: 1e941ded Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-11 22:26:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1e941dedad0ff6282ca4c1d2d71512974c97fc5e 8275197: Remove unused fields in ThaiBuddhistChronology Reviewed-by: naoto, rriggs, iris ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistChronology.java Changeset: 6b833db3 Author: Per Liden Date: 2021-11-12 08:19:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6b833db3f9cace8fbb09bb803ba31208e37a4622 8275329: ZGC: vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with assert(_phases->length() <= 1000) failed: Too many recored phases? Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/shared/gcTimer.cpp Changeset: 710f4964 Author: Nils Eliasson Date: 2021-11-12 10:08:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/710f496456d642c3e98d230270598f0b2dc75aba 8273277: C2: Move conditional negation into rc_predicate Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopopts/TestSkeletonPredicateNegation.java ! test/hotspot/jtreg/vmTestbase/jit/t/t105/t105.java Changeset: 4ae4c4ca Author: duke Date: 2021-11-12 11:00:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ae4c4cacd2ed8eaad42b052a23797e2073a57f3 Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Nov 12 11:08:09 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 12 Nov 2021 11:08:09 GMT Subject: [foreign-memaccess+abi] RFR: Merge master Message-ID: <-hj--gWVgb1y9fP1rpkTvvy1oveNNTzhHVZ5GNA77jc=.d825add5-d395-4ddd-88c5-d88a5bb21e34@github.com> Hi all, this is an _automatically_ generated pull request to notify you that there are 94 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: The following file contains merge conflicts: - src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. # Ensure target branch is up to date $ git checkout foreign-memaccess+abi $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi # Fetch and checkout the branch for this pull request $ git fetch https://github.com/openjdk-bot/panama-foreign.git +105:openjdk-bot-105 $ git checkout openjdk-bot-105 # Merge the target branch $ git merge foreign-memaccess+abi When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: $ git add paths/to/files/with/conflicts $ git commit -m 'Merge master' When you have created the merge commit, run the following command to push the merge commit to this pull request: $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-105:105 _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. Thanks, J. Duke ------------- Commit messages: - Automatic merge of jdk:master into master - 8273277: C2: Move conditional negation into rc_predicate - 8275329: ZGC: vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with assert(_phases->length() <= 1000) failed: Too many recored phases? - 8275197: Remove unused fields in ThaiBuddhistChronology - 8186670: Implement _onSpinWait() intrinsic for AArch64 - 8276265: jcmd man page is outdated - 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges - 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp - 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out" - 8079267: [TEST_BUG] Test java/awt/Frame/MiscUndecorated/RepaintTest.java fails - ... and 84 more: https://git.openjdk.java.net/panama-foreign/compare/a4e8d061...4ae4c4ca The webrev contains the conflicts with foreign-memaccess+abi: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=612&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/612/files Stats: 12026 lines in 460 files changed: 8492 ins; 1894 del; 1640 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/612.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/612/head:pull/612 PR: https://git.openjdk.java.net/panama-foreign/pull/612 From martin.pernollet at protonmail.com Fri Nov 12 12:01:04 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Fri, 12 Nov 2021 12:01:04 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <3e7f733c-6bd8-d8b2-4c45-6b352d95311c@oracle.com> <2c532257-b23b-6a24-3a6d-c841619eb97b@oracle.com> <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> Message-ID: Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows : public class glut_h extends glut_h_3 { static { System.loadLibrary("GL"); System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT"); } while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW. Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir. So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception : PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1 [...] freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32 WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator ERROR: jextract exited with non-zero exit code: 3 Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 : 358: #ifndef _CRT_TERMINATE_DEFINED 359: #define _CRT_TERMINATE_DEFINED 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN; I should mention that - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct. - I verified GCC and G++ are callable from Powershell - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself. Is this stdlib error something some of you already faced? How did you fix? Thanks! Sent with ProtonMail Secure Email. ??????? Original Message ??????? Le lundi 18 octobre 2021 ? 11:29, Rado Smogura a ?crit : > Hi Martin, > > Let me answer the last questions about JExtract and .h files for every > > platform. > > It may be needed to do separate bindings, unless you can prove > > otherwise. The specifications provides .h files and names, but may not > > be clear if, > > - given name is variable, or define > - values set to const / variable > - expr() is method or define > > There was one experiment with POSIX, where even so standard things like > > net may differ on values assigned to DEFINED between Linux & OSX. > > Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other, > > and this values will be "inlined" into extracted code. > > However how exactly is with OpenGL I don't know. > > Kind regards, > > Rado > > On 17.10.2021 15:20, Martin Pernollet wrote: > > > Report about more intensive use of foreign function API > > > > I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn?t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow : > > > > void onIdle() { > > > > throw new IllegalArgumentException("Teapot does not support coffee"); > > > > } > > > > My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412. > > > > I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before. > > > > Integration in an AWT Canvas > > > > Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU. > > > > It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc. > > > > I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL. > > > > Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) > > > > I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way). > > > > More practical questions about JExtract > > > > I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case. > > > > Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM? > > > > Thanks for reading! > > > > Martin > > > > [0] https://github.com/jzy3d/panama-gl > > > > [1] https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html > > > > [2] https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl From jvernee at openjdk.java.net Fri Nov 12 12:44:54 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 12 Nov 2021 12:44:54 GMT Subject: [foreign-memaccess+abi] RFR: 8276987: Optimized upcall stub should be printed with -XX:+PrintStubCode In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 08:21:27 GMT, Nick Gasson wrote: > That would allow it to be found by JMH's profasm which uses `-XX:+PrintStubCode` to collect the addresses of stubs. Note that JMH at the moment can't actually parse the stubs printed by `trace_new_stub` (because they have a "Decoding ..." prefix and don't include the end address), but that can be fixed on the JMH side. Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/611 From duke at openjdk.java.net Fri Nov 12 12:54:41 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 12 Nov 2021 12:54:41 GMT Subject: [foreign-memaccess+abi] RFR: Merge master [v2] In-Reply-To: <-hj--gWVgb1y9fP1rpkTvvy1oveNNTzhHVZ5GNA77jc=.d825add5-d395-4ddd-88c5-d88a5bb21e34@github.com> References: <-hj--gWVgb1y9fP1rpkTvvy1oveNNTzhHVZ5GNA77jc=.d825add5-d395-4ddd-88c5-d88a5bb21e34@github.com> Message-ID: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 94 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following file contains merge conflicts: > > - src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-memaccess+abi > $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +105:openjdk-bot-105 > $ git checkout openjdk-bot-105 > > # Merge the target branch > $ git merge foreign-memaccess+abi > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-105:105 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke J. Duke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 95 commits: - Merge branch 'foreign-memaccess+abi' into 105 - Automatic merge of jdk:master into master - 8273277: C2: Move conditional negation into rc_predicate Reviewed-by: thartmann, chagedorn, kvn - 8275329: ZGC: vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with assert(_phases->length() <= 1000) failed: Too many recored phases? Reviewed-by: stefank, eosterlund - 8275197: Remove unused fields in ThaiBuddhistChronology Reviewed-by: naoto, rriggs, iris - 8186670: Implement _onSpinWait() intrinsic for AArch64 Reviewed-by: phh, aph - 8276265: jcmd man page is outdated Reviewed-by: stuefe, cjplummer - 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges Reviewed-by: rriggs, naoto - 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp Reviewed-by: alanb - 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out" Reviewed-by: dfuchs - ... and 85 more: https://git.openjdk.java.net/panama-foreign/compare/9e9ba2e9...3e40e459 ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/612/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=612&range=01 Stats: 12027 lines in 460 files changed: 8492 ins; 1894 del; 1641 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/612.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/612/head:pull/612 PR: https://git.openjdk.java.net/panama-foreign/pull/612 From jvernee at openjdk.java.net Fri Nov 12 13:38:45 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 12 Nov 2021 13:38:45 GMT Subject: [foreign-memaccess+abi] RFR: 8276987: Optimized upcall stub should be printed with -XX:+PrintStubCode In-Reply-To: References: Message-ID: <8koPZmIjfv8avotyEAcqsmwBViCGCnvqbrUACDJV5wo=.e18c9145-485f-4b13-aaf0-0447b05d7d71@github.com> On Fri, 12 Nov 2021 08:21:27 GMT, Nick Gasson wrote: > That would allow it to be found by JMH's profasm which uses `-XX:+PrintStubCode` to collect the addresses of stubs. Note that JMH at the moment can't actually parse the stubs printed by `trace_new_stub` (because they have a "Decoding ..." prefix and don't include the end address), but that can be fixed on the JMH side. Thanks! I think in the future we could probably also remove TraceOptimziedUpcallStubs in favor of PrintStubCode. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/611 From jorn.vernee at oracle.com Fri Nov 12 14:17:20 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 12 Nov 2021 15:17:20 +0100 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <3e7f733c-6bd8-d8b2-4c45-6b352d95311c@oracle.com> <2c532257-b23b-6a24-3a6d-c841619eb97b@oracle.com> <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> Message-ID: Hi Martin, Thanks for testing this! The UnsatisfiedLinkError is not from code looking for a header file, it's from looking for a library/.dll file named GL.dll. On Windows though, freeglut needs the opengl libraries that come bundled with Windows (found in C:\Windows\System32), named opengl32 and glu32. The script should already add -l flags for those. --- WRT the jextract error you see. I have not tried to run the sample with freeglut installed through MingW yet. I instead used the freeglut package for MSVC here: https://www.transmissionzero.co.uk/software/freeglut-devel/ extracted that in some folder, and the pointed freeglutPath at that folder. Note that jextract is using clang underneath to do the parsing. I know clang works pretty well with MSVC/Windows SDK header files, but I'm guessing it can not understand the MingW headers, looking at your error. I think it's having problems with __MINGW_NOTHROW and __MINGW_ATTRIB_NORETURN, which look like compiler builtins. I'd suggest trying the freeglut package I linked to instead, together with the Windows SDK headers (which clang should find automatically), and taking MingW headers out of the equation for now. We should probably create a README for that sample to include instructions on how to get freeglut. Note that on top of that, you will also have to change Teapot.java to account for a change in parameter names resulting in slightly different code being generated by jextract [1]. HTH, Jorn [1] : diff --git a/opengl/Teapot.java b/opengl/Teapot.java index 22d1f44..d5eb786 100644 --- a/opengl/Teapot.java +++ b/opengl/Teapot.java @@ -79,8 +79,8 @@ public class Teapot { ???????????? glutInitWindowSize(500, 500); glutCreateWindow(allocator.allocateUtf8String("Hello Panama!")); ???????????? var teapot = new Teapot(allocator); -??????????? var displayStub = glutDisplayFunc$func.allocate(teapot::display, scope); -??????????? var idleStub = glutIdleFunc$func.allocate(teapot::onIdle, scope); +??????????? var displayStub = glutDisplayFunc$callback.allocate(teapot::display, scope); +??????????? var idleStub = glutIdleFunc$callback.allocate(teapot::onIdle, scope); ???????????? glutDisplayFunc(displayStub); ???????????? glutIdleFunc(idleStub); ???????????? glutMainLoop(); On 12/11/2021 13:01, Martin Pernollet wrote: > Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows : > > public class glut_h extends glut_h_3 { > static { > System.loadLibrary("GL"); > System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT"); > } > > while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW. > > Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir. > > > > So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception : > > PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1 > [...] > freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32 > WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract > C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator > ERROR: jextract exited with non-zero exit code: 3 > > Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 : > > 358: #ifndef _CRT_TERMINATE_DEFINED > 359: #define _CRT_TERMINATE_DEFINED > 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; > 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN; > > I should mention that > - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct. > - I verified GCC and G++ are callable from Powershell > - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself. > > Is this stdlib error something some of you already faced? How did you fix? > > Thanks! > > Sent with ProtonMail Secure Email. > > ??????? Original Message ??????? > > Le lundi 18 octobre 2021 ? 11:29, Rado Smogura a ?crit : > >> Hi Martin, >> >> Let me answer the last questions about JExtract and .h files for every >> >> platform. >> >> It may be needed to do separate bindings, unless you can prove >> >> otherwise. The specifications provides .h files and names, but may not >> >> be clear if, >> >> - given name is variable, or define >> - values set to const / variable >> - expr() is method or define >> >> There was one experiment with POSIX, where even so standard things like >> >> net may differ on values assigned to DEFINED between Linux & OSX. >> >> Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other, >> >> and this values will be "inlined" into extracted code. >> >> However how exactly is with OpenGL I don't know. >> >> Kind regards, >> >> Rado >> >> On 17.10.2021 15:20, Martin Pernollet wrote: >> >>> Report about more intensive use of foreign function API >>> >>> I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn?t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow : >>> >>> void onIdle() { >>> >>> throw new IllegalArgumentException("Teapot does not support coffee"); >>> >>> } >>> >>> My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412. >>> >>> I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before. >>> >>> Integration in an AWT Canvas >>> >>> Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU. >>> >>> It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc. >>> >>> I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL. >>> >>> Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) >>> >>> I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way). >>> >>> More practical questions about JExtract >>> >>> I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case. >>> >>> Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM? >>> >>> Thanks for reading! >>> >>> Martin >>> >>> [0] https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl__;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8bHkQ00p$ >>> >>> [1] https://urldefense.com/v3/__https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html__;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8ROseeEa$ >>> >>> [2] https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl__;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8WkFrawU$ From martin.pernollet at protonmail.com Fri Nov 12 14:47:56 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Fri, 12 Nov 2021 14:47:56 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> Message-ID: Thanks Jon, MinGW did not create a GL.dll file but rather libfreeglut.dll so I changed to public class glut_h extends glut_h_3 { static { System.loadLibrary("libfreeglut"); But it still fails, this time due to unresolved dependencies. Dependency Walker reveals tons of unreachable DLL (see screenshot). This failed attempt is documented here https://github.com/jzy3d/panama-gl/issues/11 I'll follow your suggestion and update documentation and notify you once I got it working. ??????? Original Message ??????? Le vendredi 12 novembre 2021 ? 15:17, Jorn Vernee a ?crit : > Hi Martin, > > Thanks for testing this! > > The UnsatisfiedLinkError is not from code looking for a header file, > > it's from looking for a library/.dll file named GL.dll. On Windows > > though, freeglut needs the opengl libraries that come bundled with > > Windows (found in C:\Windows\System32), named opengl32 and glu32. The > > script should already add -l flags for those. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > WRT the jextract error you see. > > I have not tried to run the sample with freeglut installed through MingW > > yet. I instead used the freeglut package for MSVC here: > > https://www.transmissionzero.co.uk/software/freeglut-devel/ extracted > > that in some folder, and the pointed freeglutPath at that folder. > > Note that jextract is using clang underneath to do the parsing. I know > > clang works pretty well with MSVC/Windows SDK header files, but I'm > > guessing it can not understand the MingW headers, looking at your error. > > I think it's having problems with __MINGW_NOTHROW and > > __MINGW_ATTRIB_NORETURN, which look like compiler builtins. > > I'd suggest trying the freeglut package I linked to instead, together > > with the Windows SDK headers (which clang should find automatically), > > and taking MingW headers out of the equation for now. We should probably > > create a README for that sample to include instructions on how to get > > freeglut. > > Note that on top of that, you will also have to change Teapot.java to > > account for a change in parameter names resulting in slightly different > > code being generated by jextract [1]. > > HTH, > > Jorn > > [1] : > > diff --git a/opengl/Teapot.java b/opengl/Teapot.java > > index 22d1f44..d5eb786 100644 > > --- a/opengl/Teapot.java > > +++ b/opengl/Teapot.java > > @@ -79,8 +79,8 @@ public class Teapot { > > ???????????? glutInitWindowSize(500, 500); > > glutCreateWindow(allocator.allocateUtf8String("Hello Panama!")); > > ???????????? var teapot = new Teapot(allocator); > > -??????????? var displayStub = > > glutDisplayFunc$func.allocate(teapot::display, scope); > > -??????????? var idleStub = glutIdleFunc$func.allocate(teapot::onIdle, > > scope); > > +??????????? var displayStub = > > glutDisplayFunc$callback.allocate(teapot::display, scope); > > +??????????? var idleStub = > > glutIdleFunc$callback.allocate(teapot::onIdle, scope); > > ???????????? glutDisplayFunc(displayStub); > > ???????????? glutIdleFunc(idleStub); > > ???????????? glutMainLoop(); > > On 12/11/2021 13:01, Martin Pernollet wrote: > > > Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows : > > > > public class glut_h extends glut_h_3 { > > > > static { > > > > System.loadLibrary("GL"); > > > > System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT"); > > > > } > > > > while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW. > > > > Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir. > > > > So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception : > > > > PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1 > > > > [...] > > > > freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32 > > > > WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract > > > > C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator > > > > ERROR: jextract exited with non-zero exit code: 3 > > > > Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 : > > > > 358: #ifndef _CRT_TERMINATE_DEFINED > > > > 359: #define _CRT_TERMINATE_DEFINED > > > > 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; > > > > 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN; > > > > I should mention that > > > > - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct. > > - I verified GCC and G++ are callable from Powershell > > - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself. > > > > Is this stdlib error something some of you already faced? How did you fix? > > > > Thanks! > > > > Sent with ProtonMail Secure Email. > > > > ??????? Original Message ??????? > > > > Le lundi 18 octobre 2021 ? 11:29, Rado Smogura mail at smogura.eu a ?crit : > > > > > Hi Martin, > > > > > > Let me answer the last questions about JExtract and .h files for every > > > > > > platform. > > > > > > It may be needed to do separate bindings, unless you can prove > > > > > > otherwise. The specifications provides .h files and names, but may not > > > > > > be clear if, > > > > > > - given name is variable, or define > > > > > > - values set to const / variable > > > > > > - expr() is method or define > > > > > > There was one experiment with POSIX, where even so standard things like > > > > > > net may differ on values assigned to DEFINED between Linux & OSX. > > > > > > Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other, > > > > > > and this values will be "inlined" into extracted code. > > > > > > However how exactly is with OpenGL I don't know. > > > > > > Kind regards, > > > > > > Rado > > > > > > On 17.10.2021 15:20, Martin Pernollet wrote: > > > > > > > > > > Report about more intensive use of foreign function API > > > > > > > > I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn?t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow : > > > > > > > > void onIdle() { > > > > > > > > throw new IllegalArgumentException("Teapot does not support coffee"); > > > > > > > > } > > > > > > > > My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412. > > > > > > > > I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before. > > > > > > > > Integration in an AWT Canvas > > > > > > > > Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU. > > > > > > > > It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc. > > > > > > > > I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL. > > > > > > > > Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) > > > > > > > > I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way). > > > > > > > > More practical questions about JExtract > > > > > > > > I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case. > > > > > > > > Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM? > > > > > > > > Thanks for reading! > > > > > > > > Martin > > > > > > > > [0] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8bHkQ00p$ > > > > > > > > [1] https://urldefense.com/v3/https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8ROseeEa$ > > > > > > > > [2] https://urldefense.com/v3/https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8WkFrawU$ From martin.pernollet at protonmail.com Fri Nov 12 15:09:29 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Fri, 12 Nov 2021 15:09:29 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: =?us-ascii?Q?___<8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com>__<3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a=5Frexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=3D@protonmail.com>____?= Message-ID: When I now try with the precompiled freeglut you suggest I got a jextract crash. My exact command was C:\Program" "Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe ` -I "C:\Users\Martin\Dev\jzy3d\external\freeglut\include" ` "-l" opengl32 ` "-l" glu32 ` "-l" freeglut ` "-t" "opengl" ` "--" ` "C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h" And the core dump file says # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (codeBuffer.cpp:972), pid=8664, tid=17112 # guarantee(sect->end() <= tend) failed: sanity # # JRE version: OpenJDK Runtime Environment (17.0+3) (build 17-panama+3-167) # Java VM: OpenJDK 64-Bit Server VM (17-panama+3-167, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # No core dump will be written. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h Host: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 8 cores, 15G, Windows 10 , 64 bit Build 19041 (10.0.19041.1348) Time: Fri Nov 12 16:06:50 2021 Europe de l , 64 bit Build 19041 (10.0.19041.1348) elapsed time: 0.603555 seconds (0d 0h 0m 0s) --------------- T H R E A D --------------- Current thread (0x000001beaa55be10): JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] Stack: [0x0000003933800000,0x0000003933900000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x668f4a] V [jvm.dll+0x7c69a9] V [jvm.dll+0x7c814e] V [jvm.dll+0x7c8757] V [jvm.dll+0x23ec9c] V [jvm.dll+0x1f92d0] V [jvm.dll+0x795431] V [jvm.dll+0x792fa9] C 0x000001beb1dfd661 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j jdk.internal.foreign.abi.ProgrammableUpcallHandler.allocateOptimizedUpcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/ABIDescriptor;Ljdk/internal/foreign/abi/ProgrammableUpcallHandler$CallRegs;)J+0 jdk.incubator.foreign at 17-panama j jdk.internal.foreign.abi.ProgrammableUpcallHandler.make(Ljdk/internal/foreign/abi/ABIDescriptor;Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/CallingSequence;)Ljdk/internal/foreign/abi/UpcallHandler;+380 jdk.incubator.foreign at 17-panama j jdk.internal.foreign.abi.x64.windows.CallArranger.arrangeUpcall(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;Ljdk/incubator/foreign/FunctionDescriptor;)Ljdk/internal/foreign/abi/UpcallHandler;+28 jdk.incubator.foreign at 17-panama j jdk.internal.foreign.abi.x64.windows.Windowsx64Linker.upcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/incubator/foreign/FunctionDescriptor;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+35 jdk.incubator.foreign at 17-panama j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+34 jdk.incubator.jextract at 17-panama j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;)Ljdk/incubator/foreign/MemoryAddress;+7 jdk.incubator.jextract at 17-panama j jdk.internal.clang.libclang.CXCursorVisitor.allocate(Ljdk/internal/clang/libclang/CXCursorVisitor;)Ljdk/incubator/foreign/MemoryAddress;+8 jdk.incubator.jextract at 17-panama j jdk.internal.clang.Cursor$CursorChildren.()V+15 jdk.incubator.jextract at 17-panama v ~StubRoutines::call_stub j jdk.internal.clang.Cursor.children()Ljava/util/stream/Stream;+1 jdk.incubator.jextract at 17-panama j jdk.internal.jextract.impl.Parser.parse(Ljava/nio/file/Path;Ljava/util/Collection;)Ljdk/incubator/jextract/Declaration$Scoped;+66 jdk.incubator.jextract at 17-panama j jdk.incubator.jextract.JextractTool.parse(Ljava/util/List;[Ljava/lang/String;)Ljdk/incubator/jextract/Declaration$Scoped;+55 jdk.incubator.jextract at 17-panama j jdk.incubator.jextract.JextractTool.run([Ljava/lang/String;)I+904 jdk.incubator.jextract at 17-panama j jdk.incubator.jextract.JextractTool.main([Ljava/lang/String;)V+46 jdk.incubator.jextract at 17-panama v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Threads class SMR info: _java_thread_list=0x000001bece7196e0, length=13, elements={ 0x000001beaa55be10, 0x000001becd023240, 0x000001becd023e00, 0x000001becd0394b0, 0x000001becd03a070, 0x000001becd03ea50, 0x000001becd03f410, 0x000001becd0401b0, 0x000001becd041400, 0x000001becd042e10, 0x000001becdc945a0, 0x000001becdcab950, 0x000001becdf7e080 } Java Threads: ( => current thread ) =>0x000001beaa55be10 JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] 0x000001becd023240 JavaThread "Reference Handler" daemon [_thread_blocked, id=16356, stack(0x0000003933f00000,0x0000003934000000)] 0x000001becd023e00 JavaThread "Finalizer" daemon [_thread_blocked, id=6204, stack(0x0000003934000000,0x0000003934100000)] 0x000001becd0394b0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=972, stack(0x0000003934100000,0x0000003934200000)] 0x000001becd03a070 JavaThread "Attach Listener" daemon [_thread_blocked, id=2084, stack(0x0000003934200000,0x0000003934300000)] 0x000001becd03ea50 JavaThread "Service Thread" daemon [_thread_blocked, id=18128, stack(0x0000003934300000,0x0000003934400000)] 0x000001becd03f410 JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=3404, stack(0x0000003934400000,0x0000003934500000)] 0x000001becd0401b0 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=10160, stack(0x0000003934500000,0x0000003934600000)] 0x000001becd041400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=15728, stack(0x0000003934600000,0x0000003934700000)] 0x000001becd042e10 JavaThread "Sweeper thread" daemon [_thread_blocked, id=3932, stack(0x0000003934700000,0x0000003934800000)] 0x000001becdc945a0 JavaThread "Notification Thread" daemon [_thread_blocked, id=12368, stack(0x0000003934800000,0x0000003934900000)] 0x000001becdcab950 JavaThread "Common-Cleaner" daemon [_thread_blocked, id=15996, stack(0x0000003934a00000,0x0000003934b00000)] 0x000001becdf7e080 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=8236, stack(0x0000003934e00000,0x0000003934f00000)] Other Threads: 0x000001becd01c730 VMThread "VM Thread" [stack: 0x0000003933e00000,0x0000003933f00000] [id=8136] 0x000001becd00d9b0 WatcherThread [stack: 0x0000003934900000,0x0000003934a00000] [id=11228] 0x000001beaa5a9a40 GCTaskThread "GC Thread#0" [stack: 0x0000003933900000,0x0000003933a00000] [id=15472] 0x000001becde6f060 GCTaskThread "GC Thread#1" [stack: 0x0000003934b00000,0x0000003934c00000] [id=9408] 0x000001becde782a0 GCTaskThread "GC Thread#2" [stack: 0x0000003934c00000,0x0000003934d00000] [id=15952] 0x000001becde78560 GCTaskThread "GC Thread#3" [stack: 0x0000003934d00000,0x0000003934e00000] [id=17212] 0x000001bece9140e0 GCTaskThread "GC Thread#4" [stack: 0x0000003934f00000,0x0000003935000000] [id=13940] 0x000001bece914ea0 GCTaskThread "GC Thread#5" [stack: 0x0000003935000000,0x0000003935100000] [id=12744] 0x000001beaa5ba550 ConcurrentGCThread "G1 Main Marker" [stack: 0x0000003933a00000,0x0000003933b00000] [id=9236] 0x000001beaa5bbf70 ConcurrentGCThread "G1 Conc#0" [stack: 0x0000003933b00000,0x0000003933c00000] [id=17776] 0x000001beaa5e6a80 ConcurrentGCThread "G1 Refine#0" [stack: 0x0000003933c00000,0x0000003933d00000] [id=1088] 0x000001beaa5e84c0 ConcurrentGCThread "G1 Service" [stack: 0x0000003933d00000,0x0000003933e00000] [id=3248] Threads with active compile tasks: C2 CompilerThread0 608 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) VM state: not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap address: 0x0000000704400000, size: 4028 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 CDS archive(s) mapped at: [0x0000000800000000-0x0000000800bb0000-0x0000000800bb0000), size 12255232, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. Compressed class space mapped at: 0x0000000800c00000-0x0000000840c00000, reserved size: 1073741824 Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 GC Precious Log: CPUs: 8 total, 8 available Memory: 16107M Large Page Support: Disabled NUMA Support: Disabled Compressed Oops: Enabled (Zero based) Heap Region Size: 2M Heap Min Capacity: 8M Heap Initial Capacity: 8M Heap Max Capacity: 4028M Pre-touch: Disabled Parallel Workers: 8 Concurrent Workers: 2 Concurrent Refinement Workers: 8 Periodic GC: Disabled Heap: garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) region size 2048K, 2 young (4096K), 1 survivors (2048K) Metaspace used 4346K, committed 5056K, reserved 1056768K class space used 589K, committed 896K, reserved 1048576K Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts), HC=humongous(continues), CS=collection set, F=free, OA=open archive, CA=closed archive, TAMS=top-at-mark-start (previous, next) | 0|0x0000000704400000, 0x00000007044e4e00, 0x0000000704600000| 44%| O| |TAMS 0x0000000704400000, 0x0000000704400000| Untracked | 1|0x0000000704600000, 0x0000000704600000, 0x0000000704800000| 0%| F| |TAMS 0x0000000704600000, 0x0000000704600000| Untracked | 2|0x0000000704800000, 0x00000007048fb810, 0x0000000704a00000| 49%| S|CS|TAMS 0x0000000704800000, 0x0000000704800000| Complete | 3|0x0000000704a00000, 0x0000000704bfa230, 0x0000000704c00000| 98%| E| |TAMS 0x0000000704a00000, 0x0000000704a00000| Complete Card table byte_map: [0x000001bec1900000,0x000001bec20e0000] _byte_map_base: 0x000001bebe0de000 Marking Bits (Prev, Next): (CMBitMap*) 0x000001beaa5aa060, (CMBitMap*) 0x000001beaa5aa0a0 Prev Bits: [0x000001bec28c0000, 0x000001bec67b0000) Next Bits: [0x000001bec67b0000, 0x000001beca6a0000) Polling page: 0x000001bea8380000 Metaspace: Usage: Non-class: 3.67 MB used. Class: 589.17 KB used. Both: 4.24 MB used. Virtual space: Non-class space: 8.00 MB reserved, 4.06 MB ( 51%) committed, 1 nodes. Class space: 1.00 GB reserved, 896.00 KB ( <1%) committed, 1 nodes. Both: 1.01 GB reserved, 4.94 MB ( <1%) committed. Chunk freelists: Non-Class: 2.55 MB Class: 2.96 MB Both: 5.51 MB MaxMetaspaceSize: unlimited CompressedClassSpaceSize: 1.00 GB Initial GC threshold: 21.00 MB Current GC threshold: 21.00 MB CDS: on MetaspaceReclaimPolicy: balanced - commit_granule_bytes: 65536. - commit_granule_words: 8192. - virtual_space_node_default_size: 1048576. - enlarge_chunks_in_place: 1. - new_chunks_are_fully_committed: 0. - uncommit_free_chunks: 1. - use_allocation_guard: 0. - handle_deallocations: 1. Internal statistics: num_allocs_failed_limit: 0. num_arena_births: 990. num_arena_deaths: 0. num_vsnodes_births: 2. num_vsnodes_deaths: 0. num_space_committed: 79. num_space_uncommitted: 0. num_chunks_returned_to_freelist: 0. num_chunks_taken_from_freelist: 1166. num_chunk_merges: 0. num_chunk_splits: 758. num_chunks_enlarged: 370. num_purges: 0. CodeHeap 'non-profiled nmethods': size=120000Kb used=542Kb max_used=542Kb free=119458Kb bounds [0x000001beb98c0000, 0x000001beb9b30000, 0x000001bec0df0000] CodeHeap 'profiled nmethods': size=120000Kb used=1537Kb max_used=1537Kb free=118462Kb bounds [0x000001beb2390000, 0x000001beb2600000, 0x000001beb98c0000] CodeHeap 'non-nmethods': size=5760Kb used=1214Kb max_used=1246Kb free=4545Kb bounds [0x000001beb1df0000, 0x000001beb2060000, 0x000001beb2390000] total_blobs=1537 nmethods=1035 adapters=412 compilation: enabled stopped_count=0, restarted_count=0 full_count=0 Compilation events (20 events): Event: 0.590 Thread 0x000001becd041400 1020 3 java.lang.invoke.DirectMethodHandle:: (148 bytes) Event: 0.591 Thread 0x000001becd0401b0 nmethod 1019 0x000001beb9945710 code [0x000001beb9945880, 0x000001beb9945958] Event: 0.591 Thread 0x000001becd041400 nmethod 1020 0x000001beb2508510 code [0x000001beb25087c0, 0x000001beb2509748] Event: 0.591 Thread 0x000001becd0401b0 1021 4 jdk.internal.org.objectweb.asm.Frame::getLocal (46 bytes) Event: 0.591 Thread 0x000001becd0401b0 nmethod 1021 0x000001beb9946010 code [0x000001beb9946180, 0x000001beb9946258] Event: 0.592 Thread 0x000001becd041400 1024 3 java.lang.invoke.LambdaFormEditor$TransformKey::of (51 bytes) Event: 0.593 Thread 0x000001becd041400 nmethod 1024 0x000001beb2509c90 code [0x000001beb2509e80, 0x000001beb250a448] Event: 0.593 Thread 0x000001becd041400 1025 3 java.lang.invoke.LambdaFormEditor$TransformKey::packedBytes (39 bytes) Event: 0.593 Thread 0x000001becd041400 nmethod 1025 0x000001beb250a610 code [0x000001beb250a7a0, 0x000001beb250a8b8] Event: 0.593 Thread 0x000001becdf7e080 1028 4 java.lang.invoke.LambdaForm$BasicType::basicType (19 bytes) Event: 0.593 Thread 0x000001becd0401b0 1029 4 jdk.internal.org.objectweb.asm.Frame::pop (42 bytes) Event: 0.593 Thread 0x000001becd041400 1031 3 java.lang.invoke.MethodHandles::collectArguments (47 bytes) Event: 0.593 Thread 0x000001becd0401b0 nmethod 1029 0x000001beb9946910 code [0x000001beb9946a80, 0x000001beb9946b58] Event: 0.593 Thread 0x000001becd0401b0 1030 4 jdk.internal.org.objectweb.asm.Frame::merge (317 bytes) Event: 0.593 Thread 0x000001becd041400 nmethod 1031 0x000001beb250a990 code [0x000001beb250abc0, 0x000001beb250b3e8] Event: 0.593 Thread 0x000001becd041400 1032 3 java.lang.invoke.MethodHandles::collectArgumentsChecks (124 bytes) Event: 0.594 Thread 0x000001becd0401b0 nmethod 1030 0x000001beb9946c10 code [0x000001beb9946d80, 0x000001beb9946e78] Event: 0.594 Thread 0x000001becd0401b0 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) Event: 0.594 Thread 0x000001becd041400 nmethod 1032 0x000001beb250b790 code [0x000001beb250bb00, 0x000001beb250d2b8] Event: 0.594 Thread 0x000001becd041400 1033 3 java.lang.invoke.LambdaFormEditor::collectArgumentsForm (169 bytes) GC Heap History (10 events): Event: 0.086 GC heap before {Heap before GC invocations=0 (full 0): garbage-first heap total 8192K, used 2048K [0x0000000704400000, 0x0000000800000000) region size 2048K, 1 young (2048K), 0 survivors (0K) Metaspace used 1471K, committed 1664K, reserved 1056768K class space used 151K, committed 256K, reserved 1048576K } Event: 0.088 GC heap after {Heap after GC invocations=1 (full 0): garbage-first heap total 8192K, used 1168K [0x0000000704400000, 0x0000000800000000) region size 2048K, 1 young (2048K), 1 survivors (2048K) Metaspace used 1471K, committed 1664K, reserved 1056768K class space used 151K, committed 256K, reserved 1048576K } Event: 0.135 GC heap before {Heap before GC invocations=1 (full 0): garbage-first heap total 8192K, used 3216K [0x0000000704400000, 0x0000000800000000) region size 2048K, 2 young (4096K), 1 survivors (2048K) Metaspace used 2586K, committed 2880K, reserved 1056768K class space used 297K, committed 448K, reserved 1048576K } Event: 0.137 GC heap after {Heap after GC invocations=2 (full 0): garbage-first heap total 8192K, used 1270K [0x0000000704400000, 0x0000000800000000) region size 2048K, 1 young (2048K), 1 survivors (2048K) Metaspace used 2586K, committed 2880K, reserved 1056768K class space used 297K, committed 448K, reserved 1048576K } Event: 0.165 GC heap before {Heap before GC invocations=2 (full 0): garbage-first heap total 8192K, used 3318K [0x0000000704400000, 0x0000000800000000) region size 2048K, 2 young (4096K), 1 survivors (2048K) Metaspace used 2912K, committed 3328K, reserved 1056768K class space used 360K, committed 576K, reserved 1048576K } Event: 0.167 GC heap after {Heap after GC invocations=3 (full 0): garbage-first heap total 8192K, used 1460K [0x0000000704400000, 0x0000000800000000) region size 2048K, 1 young (2048K), 1 survivors (2048K) Metaspace used 2912K, committed 3328K, reserved 1056768K class space used 360K, committed 576K, reserved 1048576K } Event: 0.366 GC heap before {Heap before GC invocations=3 (full 0): garbage-first heap total 8192K, used 3508K [0x0000000704400000, 0x0000000800000000) region size 2048K, 2 young (4096K), 1 survivors (2048K) Metaspace used 3240K, committed 3712K, reserved 1056768K class space used 418K, committed 640K, reserved 1048576K } Event: 0.368 GC heap after {Heap after GC invocations=4 (full 0): garbage-first heap total 8192K, used 1629K [0x0000000704400000, 0x0000000800000000) region size 2048K, 1 young (2048K), 1 survivors (2048K) Metaspace used 3240K, committed 3712K, reserved 1056768K class space used 418K, committed 640K, reserved 1048576K } Event: 0.570 GC heap before {Heap before GC invocations=4 (full 0): garbage-first heap total 8192K, used 3677K [0x0000000704400000, 0x0000000800000000) region size 2048K, 2 young (4096K), 1 survivors (2048K) Metaspace used 4023K, committed 4608K, reserved 1056768K class space used 525K, committed 832K, reserved 1048576K } Event: 0.572 GC heap after {Heap after GC invocations=5 (full 0): garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) region size 2048K, 1 young (2048K), 1 survivors (2048K) Metaspace used 4023K, committed 4608K, reserved 1056768K class space used 525K, committed 832K, reserved 1048576K } Deoptimization events (14 events): Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb98c3cac relative=0x000000000000020c Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb98c3cac method=java.lang.String.hashCode()I @ 42 c2 Event: 0.034 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb98c3cac sp=0x00000039338fe520 Event: 0.034 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe4b8 mode 2 Event: 0.122 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb23ab367 sp=0x00000039338fd790 Event: 0.122 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e46763 sp=0x00000039338fcbb0 mode 0 Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb990a7e0 relative=0x0000000000007740 Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb990a7e0 method=jdk.internal.org.objectweb.asm.Frame.execute(IILjdk/internal/org/objectweb/asm/Symbol;Ljdk/internal/org/objectweb/asm/SymbolTable;)V @ 1 c2 Event: 0.584 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb990a7e0 sp=0x00000039338fcef0 Event: 0.584 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fcea8 mode 2 Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffffcc fr.pc=0x000001beb9943df4 relative=0x0000000000000354 Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: reason=intrinsic_or_type_checked_inlining action=make_not_entrant pc=0x000001beb9943df4 method=java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; @ 35 c2 Event: 0.592 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb9943df4 sp=0x00000039338fe2b0 Event: 0.592 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe258 mode 2 Classes unloaded (0 events): No events Classes redefined (0 events): No events Internal exceptions (20 events): Event: 0.424 Thread 0x000001beaa55be10 Exception (0x0000000704b67fa8) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.566 Thread 0x000001beaa55be10 Exception (0x0000000704ba0908) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.572 Thread 0x000001beaa55be10 Exception (0x0000000704a048c8) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.574 Thread 0x000001beaa55be10 Exception (0x0000000704a359b8) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.576 Thread 0x000001beaa55be10 Exception (0x0000000704a69260) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.578 Thread 0x000001beaa55be10 Exception (0x0000000704a85548) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.579 Thread 0x000001beaa55be10 Exception (0x0000000704a9b548) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.581 Thread 0x000001beaa55be10 Exception (0x0000000704ac7840) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.582 Thread 0x000001beaa55be10 Exception (0x0000000704acada8) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b0f9a8) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b13248) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.588 Thread 0x000001beaa55be10 Exception (0x0000000704b66608) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b69ec0) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b72a48) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b765d8) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7a480) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7e200) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b99bd0) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b9d880) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Event: 0.593 Thread 0x000001beaa55be10 Exception (0x0000000704bd0ae8) thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] Events (20 events): Event: 0.423 loading class java/io/DeleteOnExitHook done Event: 0.423 loading class java/io/DeleteOnExitHook$1 Event: 0.424 loading class java/io/DeleteOnExitHook$1 done Event: 0.550 Thread 0x000001beceebb670 Thread exited: 0x000001beceebb670 Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator done Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef done Event: 0.551 loading class java/util/stream/Streams$2 Event: 0.551 loading class java/util/stream/Streams$2 done Event: 0.570 Executing VM operation: G1CollectForAllocation Event: 0.572 Executing VM operation: G1CollectForAllocation done Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator done Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator done Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler done Event: 0.594 loading class java/lang/invoke/MethodHandle$1 Event: 0.594 loading class java/lang/invoke/MethodHandle$1 done Dynamic libraries: 0x00007ff670d20000 - 0x00007ff670d28000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe 0x00007fff63110000 - 0x00007fff63305000 C:\Windows\SYSTEM32\ntdll.dll 0x00007fff61a00000 - 0x00007fff61abe000 C:\Windows\System32\KERNEL32.DLL 0x00007fff60960000 - 0x00007fff60c28000 C:\Windows\System32\KERNELBASE.dll 0x00007fff60830000 - 0x00007fff60930000 C:\Windows\System32\ucrtbase.dll 0x00007fff567c0000 - 0x00007fff567d8000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jli.dll 0x00007fff57310000 - 0x00007fff5732a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\VCRUNTIME140.dll 0x00007fff629b0000 - 0x00007fff62b51000 C:\Windows\System32\USER32.dll 0x00007fff60f30000 - 0x00007fff60f52000 C:\Windows\System32\win32u.dll 0x00007fff61ac0000 - 0x00007fff61aeb000 C:\Windows\System32\GDI32.dll 0x00007fff45910000 - 0x00007fff45baa000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\COMCTL32.dll 0x00007fff60c30000 - 0x00007fff60d3b000 C:\Windows\System32\gdi32full.dll 0x00007fff62fd0000 - 0x00007fff6306e000 C:\Windows\System32\msvcrt.dll 0x00007fff610c0000 - 0x00007fff6115d000 C:\Windows\System32\msvcp_win.dll 0x00007fff61160000 - 0x00007fff61190000 C:\Windows\System32\IMM32.DLL 0x00007fff5b580000 - 0x00007fff5b58c000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\vcruntime140_1.dll 0x00007fff44fa0000 - 0x00007fff4502d000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\msvcp140.dll 0x00007ffefad70000 - 0x00007ffefb920000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server\jvm.dll 0x00007fff61ef0000 - 0x00007fff61f9c000 C:\Windows\System32\ADVAPI32.dll 0x00007fff61cf0000 - 0x00007fff61d8b000 C:\Windows\System32\sechost.dll 0x00007fff62b60000 - 0x00007fff62c8a000 C:\Windows\System32\RPCRT4.dll 0x00007fff61ee0000 - 0x00007fff61ee8000 C:\Windows\System32\PSAPI.DLL 0x00007fff2dc20000 - 0x00007fff2dc29000 C:\Windows\SYSTEM32\WSOCK32.dll 0x00007fff54b80000 - 0x00007fff54b8a000 C:\Windows\SYSTEM32\VERSION.dll 0x00007fff518e0000 - 0x00007fff51907000 C:\Windows\SYSTEM32\WINMM.dll 0x00007fff61bd0000 - 0x00007fff61c3b000 C:\Windows\System32\WS2_32.dll 0x00007fff5f060000 - 0x00007fff5f072000 C:\Windows\SYSTEM32\kernel.appcore.dll 0x00007fff5b500000 - 0x00007fff5b50a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jimage.dll 0x00007fff5e430000 - 0x00007fff5e614000 C:\Windows\SYSTEM32\DBGHELP.DLL 0x00007fff45170000 - 0x00007fff4519c000 C:\Windows\SYSTEM32\dbgcore.DLL 0x00007fff60d40000 - 0x00007fff60dc3000 C:\Windows\System32\bcryptPrimitives.dll 0x00007fff44f70000 - 0x00007fff44f95000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\java.dll 0x00007fff612c0000 - 0x00007fff619ff000 C:\Windows\System32\SHELL32.dll 0x00007fff5e620000 - 0x00007fff5edb0000 C:\Windows\SYSTEM32\windows.storage.dll 0x00007fff62650000 - 0x00007fff629a5000 C:\Windows\System32\combase.dll 0x00007fff60280000 - 0x00007fff602ae000 C:\Windows\SYSTEM32\Wldp.dll 0x00007fff61c40000 - 0x00007fff61ced000 C:\Windows\System32\SHCORE.dll 0x00007fff62f70000 - 0x00007fff62fc5000 C:\Windows\System32\shlwapi.dll 0x00007fff60770000 - 0x00007fff6078f000 C:\Windows\SYSTEM32\profapi.dll 0x00007fff44f10000 - 0x00007fff44f29000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\net.dll 0x00007fff5ada0000 - 0x00007fff5aeac000 C:\Windows\SYSTEM32\WINHTTP.dll 0x00007fff5ffe0000 - 0x00007fff6004a000 C:\Windows\system32\mswsock.dll 0x00007fff28650000 - 0x00007fff28665000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\nio.dll 0x00007ffeda3b0000 - 0x00007ffede7d1000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\libclang.dll 0x00007fff62ea0000 - 0x00007fff62f6d000 C:\Windows\System32\OLEAUT32.dll 0x00007fff61190000 - 0x00007fff612ba000 C:\Windows\System32\ole32.dll 0x00007fff5dac0000 - 0x00007fff5db5e000 C:\Windows\system32\uxtheme.dll 0x00007fff61e30000 - 0x00007fff61ed9000 C:\Windows\System32\clbcatq.dll 0x00007fff601d0000 - 0x00007fff601e8000 C:\Windows\SYSTEM32\CRYPTSP.dll 0x00007fff5f8c0000 - 0x00007fff5f8f4000 C:\Windows\system32\rsaenh.dll 0x00007fff60930000 - 0x00007fff60957000 C:\Windows\System32\bcrypt.dll 0x00007fff60730000 - 0x00007fff6075e000 C:\Windows\SYSTEM32\USERENV.dll 0x00007fff601f0000 - 0x00007fff601fc000 C:\Windows\SYSTEM32\CRYPTBASE.dll 0x00007fff5fc80000 - 0x00007fff5fcbb000 C:\Windows\SYSTEM32\IPHLPAPI.DLL 0x00007fff62550000 - 0x00007fff62558000 C:\Windows\System32\NSI.dll 0x00007fff55080000 - 0x00007fff55097000 C:\Windows\SYSTEM32\dhcpcsvc6.DLL 0x00007fff55060000 - 0x00007fff5507d000 C:\Windows\SYSTEM32\dhcpcsvc.DLL 0x00007fff5fcd0000 - 0x00007fff5fd9b000 C:\Windows\SYSTEM32\DNSAPI.dll dbghelp: loaded successfully - version: 4.0.5 - missing functions: none symbol engine: initialized successfully - sym options: 0x614 - pdb path: .;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin;C:\Windows\SYSTEM32;C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server VM Arguments: jvm_args: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract java_command: jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h java_class_path (initial): Launcher Type: SUN_STANDARD [Global flags] intx CICompilerCount = 4 {product} {ergonomic} uint ConcGCThreads = 2 {product} {ergonomic} uint G1ConcRefinementThreads = 8 {product} {ergonomic} size_t G1HeapRegionSize = 2097152 {product} {ergonomic} uintx GCDrainStackTargetSize = 64 {product} {ergonomic} size_t InitialHeapSize = 8388608 {product} {command line} size_t MarkStackSize = 4194304 {product} {ergonomic} size_t MaxHeapSize = 4223664128 {product} {ergonomic} size_t MaxNewSize = 2533359616 {product} {ergonomic} size_t MinHeapDeltaBytes = 2097152 {product} {ergonomic} size_t MinHeapSize = 8388608 {product} {command line} uintx NonNMethodCodeHeapSize = 5839372 {pd product} {ergonomic} uintx NonProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} uintx ProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} uintx ReservedCodeCacheSize = 251658240 {pd product} {ergonomic} bool SegmentedCodeCache = true {product} {ergonomic} size_t SoftMaxHeapSize = 4223664128 {manageable} {ergonomic} bool UseCompressedClassPointers = true {product lp64_product} {ergonomic} bool UseCompressedOops = true {product lp64_product} {ergonomic} bool UseG1GC = true {product} {ergonomic} bool UseLargePagesIndividualAllocation = false {pd product} {ergonomic} Logging: Log output configuration: #0: stdout all=warning uptime,level,tags #1: stderr all=off uptime,level,tags Environment Variables: JAVA_HOME=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 PATH=C:\Program Files\Zulu\zulu-11\bin\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Program Files (x86)\apache-ant-1.9.16\bin;C:\Program Files\CMake\bin;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\7-Zip;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\gawk-3.1.6-1-bin\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin;C:\Users\Martin\AppData\Local\Microsoft\WindowsApps;C:\Users\Martin\AppData\Local\atom\bin;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Users\Martin\.dotnet\tools USERNAME=Martin OS=Windows_NT PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 140 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows 10 , 64 bit Build 19041 (10.0.19041.1348) OS uptime: 0 days 4:15 hours Hyper-V role detected CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 6 model 140 stepping 1 microcode 0x86, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, avx512f, avx512dq, avx512cd, avx512bw, avx512vl, sha, fma, vzeroupper, avx512_vpopcntdq, avx512_vpclmulqdq, avx512_vaes, avx512_vnni, clflush, clflushopt, clwb, avx512_vbmi2, avx512_vbmi, hv Memory: 4k page, system-wide physical 16107M (6064M free) TotalPageFile size 20971M (AvailPageFile size 8500M) current process WorkingSet (physical memory assigned to process): 136M, peak: 147M current process commit charge ("private bytes"): 177M, peak: 191M vm_info: OpenJDK 64-Bit Server VM (17-panama+3-167) for windows-amd64 JRE (17-panama+3-167), built on May 18 2021 13:10:19 by "mach5one" with MS VC++ 16.8 (VS2019) END. Sent with ProtonMail Secure Email. ??????? Original Message ??????? Le vendredi 12 novembre 2021 ? 15:47, Martin Pernollet a ?crit : > Thanks Jon, > > MinGW did not create a GL.dll file but rather libfreeglut.dll so I changed to > > public class glut_h extends glut_h_3 { > > static { > > System.loadLibrary("libfreeglut"); > > But it still fails, this time due to unresolved dependencies. Dependency Walker reveals tons of unreachable DLL (see screenshot). > > This failed attempt is documented here https://github.com/jzy3d/panama-gl/issues/11 > > I'll follow your suggestion and update documentation and notify you once I got it working. > > ??????? Original Message ??????? > > Le vendredi 12 novembre 2021 ? 15:17, Jorn Vernee jorn.vernee at oracle.com a ?crit : > > > Hi Martin, > > > > Thanks for testing this! > > > > The UnsatisfiedLinkError is not from code looking for a header file, > > > > it's from looking for a library/.dll file named GL.dll. On Windows > > > > though, freeglut needs the opengl libraries that come bundled with > > > > Windows (found in C:\Windows\System32), named opengl32 and glu32. The > > > > script should already add -l flags for those. > > > > WRT the jextract error you see. > > > > I have not tried to run the sample with freeglut installed through MingW > > > > yet. I instead used the freeglut package for MSVC here: > > > > https://www.transmissionzero.co.uk/software/freeglut-devel/ extracted > > > > that in some folder, and the pointed freeglutPath at that folder. > > > > Note that jextract is using clang underneath to do the parsing. I know > > > > clang works pretty well with MSVC/Windows SDK header files, but I'm > > > > guessing it can not understand the MingW headers, looking at your error. > > > > I think it's having problems with __MINGW_NOTHROW and > > > > __MINGW_ATTRIB_NORETURN, which look like compiler builtins. > > > > I'd suggest trying the freeglut package I linked to instead, together > > > > with the Windows SDK headers (which clang should find automatically), > > > > and taking MingW headers out of the equation for now. We should probably > > > > create a README for that sample to include instructions on how to get > > > > freeglut. > > > > Note that on top of that, you will also have to change Teapot.java to > > > > account for a change in parameter names resulting in slightly different > > > > code being generated by jextract [1]. > > > > HTH, > > > > Jorn > > > > [1] : > > > > diff --git a/opengl/Teapot.java b/opengl/Teapot.java > > > > index 22d1f44..d5eb786 100644 > > > > --- a/opengl/Teapot.java > > > > +++ b/opengl/Teapot.java > > > > @@ -79,8 +79,8 @@ public class Teapot { > > > > glutInitWindowSize(500, 500); > > > > glutCreateWindow(allocator.allocateUtf8String("Hello Panama!")); > > > > var teapot = new Teapot(allocator); > > > > -??????????? var displayStub = > > > > glutDisplayFunc$func.allocate(teapot::display, scope); > > > > -??????????? var idleStub = glutIdleFunc$func.allocate(teapot::onIdle, > > > > scope); > > > > +??????????? var displayStub = > > > > glutDisplayFunc$callback.allocate(teapot::display, scope); > > > > +??????????? var idleStub = > > > > glutIdleFunc$callback.allocate(teapot::onIdle, scope); > > > > glutDisplayFunc(displayStub); > > > > glutIdleFunc(idleStub); > > > > glutMainLoop(); > > > > On 12/11/2021 13:01, Martin Pernollet wrote: > > > > > Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows : > > > > > > public class glut_h extends glut_h_3 { > > > > > > static { > > > > > > System.loadLibrary("GL"); > > > > > > System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT"); > > > > > > } > > > > > > while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW. > > > > > > Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir. > > > > > > So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception : > > > > > > PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1 > > > > > > [...] > > > > > > freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32 > > > > > > WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract > > > > > > C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator > > > > > > ERROR: jextract exited with non-zero exit code: 3 > > > > > > Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 : > > > > > > 358: #ifndef _CRT_TERMINATE_DEFINED > > > > > > 359: #define _CRT_TERMINATE_DEFINED > > > > > > 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; > > > > > > 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN; > > > > > > I should mention that > > > > > > - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct. > > > - I verified GCC and G++ are callable from Powershell > > > - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself. > > > > > > Is this stdlib error something some of you already faced? How did you fix? > > > > > > Thanks! > > > > > > Sent with ProtonMail Secure Email. > > > > > > ??????? Original Message ??????? > > > > > > Le lundi 18 octobre 2021 ? 11:29, Rado Smogura mail at smogura.eu a ?crit : > > > > > > > Hi Martin, > > > > > > > > Let me answer the last questions about JExtract and .h files for every > > > > > > > > platform. > > > > > > > > It may be needed to do separate bindings, unless you can prove > > > > > > > > otherwise. The specifications provides .h files and names, but may not > > > > > > > > be clear if, > > > > > > > > - given name is variable, or define > > > > > > > > - values set to const / variable > > > > > > > > - expr() is method or define > > > > > > > > There was one experiment with POSIX, where even so standard things like > > > > > > > > net may differ on values assigned to DEFINED between Linux & OSX. > > > > > > > > Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other, > > > > > > > > and this values will be "inlined" into extracted code. > > > > > > > > However how exactly is with OpenGL I don't know. > > > > > > > > Kind regards, > > > > > > > > Rado > > > > > > > > On 17.10.2021 15:20, Martin Pernollet wrote: > > > > > > > > > > > > > Report about more intensive use of foreign function API > > > > > > > > > > I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn?t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow : > > > > > > > > > > void onIdle() { > > > > > > > > > > throw new IllegalArgumentException("Teapot does not support coffee"); > > > > > > > > > > } > > > > > > > > > > My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412. > > > > > > > > > > I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before. > > > > > > > > > > Integration in an AWT Canvas > > > > > > > > > > Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU. > > > > > > > > > > It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc. > > > > > > > > > > I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL. > > > > > > > > > > Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) > > > > > > > > > > I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way). > > > > > > > > > > More practical questions about JExtract > > > > > > > > > > I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case. > > > > > > > > > > Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM? > > > > > > > > > > Thanks for reading! > > > > > > > > > > Martin > > > > > > > > > > [0] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8bHkQ00p$ > > > > > > > > > > [1] https://urldefense.com/v3/https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8ROseeEa$ > > > > > > > > > > [2] https://urldefense.com/v3/https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8WkFrawU$ From martin.pernollet at protonmail.com Fri Nov 12 15:11:16 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Fri, 12 Nov 2021 15:11:16 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> Message-ID: I should mention I used https://www.transmissionzero.co.uk/files/software/development/GLUT/freeglut-MSVC.zip, not the one for MinGW. ??????? Original Message ??????? Le vendredi 12 novembre 2021 ? 16:09, Martin Pernollet a ?crit : > When I now try with the precompiled freeglut you suggest I got a jextract crash. My exact command was > > C:\Program" "Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe `-I "C:\\Users\\Martin\\Dev\\jzy3d\\external\\freeglut\\include"` > > "-l" opengl32 `"-l" glu32` > > "-l" freeglut `"-t" "opengl"` > > "--" ` > > "C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h" > > And the core dump file says > > A fatal error has been detected by the Java Runtime Environment: > ================================================================ > > Internal Error (codeBuffer.cpp:972), pid=8664, tid=17112 > ======================================================== > > guarantee(sect->end() <= tend) failed: sanity > ============================================= > > JRE version: OpenJDK Runtime Environment (17.0+3) (build 17-panama+3-167) > ========================================================================= > > Java VM: OpenJDK 64-Bit Server VM (17-panama+3-167, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) > ============================================================================================================================================== > > No core dump will be written. Minidumps are not enabled by default on client versions of Windows > ================================================================================================ > > If you would like to submit a bug report, please visit: > ======================================================= > > https://bugreport.java.com/bugreport/crash.jsp > ============================================== > > --------------- S U M M A R Y ------------ > > Command Line: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h > > Host: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 8 cores, 15G, Windows 10 , 64 bit Build 19041 (10.0.19041.1348) > > Time: Fri Nov 12 16:06:50 2021 Europe de l , 64 bit Build 19041 (10.0.19041.1348) elapsed time: 0.603555 seconds (0d 0h 0m 0s) > > --------------- T H R E A D --------------- > > Current thread (0x000001beaa55be10): JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] > > Stack: [0x0000003933800000,0x0000003933900000] > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > > V [jvm.dll+0x668f4a] > > V [jvm.dll+0x7c69a9] > > V [jvm.dll+0x7c814e] > > V [jvm.dll+0x7c8757] > > V [jvm.dll+0x23ec9c] > > V [jvm.dll+0x1f92d0] > > V [jvm.dll+0x795431] > > V [jvm.dll+0x792fa9] > > C 0x000001beb1dfd661 > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > > j jdk.internal.foreign.abi.ProgrammableUpcallHandler.allocateOptimizedUpcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/ABIDescriptor;Ljdk/internal/foreign/abi/ProgrammableUpcallHandler$CallRegs;)J+0 jdk.incubator.foreign at 17-panama > > j jdk.internal.foreign.abi.ProgrammableUpcallHandler.make(Ljdk/internal/foreign/abi/ABIDescriptor;Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/CallingSequence;)Ljdk/internal/foreign/abi/UpcallHandler;+380 jdk.incubator.foreign at 17-panama > > j jdk.internal.foreign.abi.x64.windows.CallArranger.arrangeUpcall(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;Ljdk/incubator/foreign/FunctionDescriptor;)Ljdk/internal/foreign/abi/UpcallHandler;+28 jdk.incubator.foreign at 17-panama > > j jdk.internal.foreign.abi.x64.windows.Windowsx64Linker.upcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/incubator/foreign/FunctionDescriptor;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+35 jdk.incubator.foreign at 17-panama > > j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+34 jdk.incubator.jextract at 17-panama > > j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;)Ljdk/incubator/foreign/MemoryAddress;+7 jdk.incubator.jextract at 17-panama > > j jdk.internal.clang.libclang.CXCursorVisitor.allocate(Ljdk/internal/clang/libclang/CXCursorVisitor;)Ljdk/incubator/foreign/MemoryAddress;+8 jdk.incubator.jextract at 17-panama > > j jdk.internal.clang.Cursor$CursorChildren.()V+15 jdk.incubator.jextract at 17-panama > > v ~StubRoutines::call_stub > > j jdk.internal.clang.Cursor.children()Ljava/util/stream/Stream;+1 jdk.incubator.jextract at 17-panama > > j jdk.internal.jextract.impl.Parser.parse(Ljava/nio/file/Path;Ljava/util/Collection;)Ljdk/incubator/jextract/Declaration$Scoped;+66 jdk.incubator.jextract at 17-panama > > j jdk.incubator.jextract.JextractTool.parse(Ljava/util/List;[Ljava/lang/String;)Ljdk/incubator/jextract/Declaration$Scoped;+55 jdk.incubator.jextract at 17-panama > > j jdk.incubator.jextract.JextractTool.run([Ljava/lang/String;)I+904 jdk.incubator.jextract at 17-panama > > j jdk.incubator.jextract.JextractTool.main([Ljava/lang/String;)V+46 jdk.incubator.jextract at 17-panama > > v ~StubRoutines::call_stub > > --------------- P R O C E S S --------------- > > Threads class SMR info: > > _java_thread_list=0x000001bece7196e0, length=13, elements={ > > 0x000001beaa55be10, 0x000001becd023240, 0x000001becd023e00, 0x000001becd0394b0, > > 0x000001becd03a070, 0x000001becd03ea50, 0x000001becd03f410, 0x000001becd0401b0, > > 0x000001becd041400, 0x000001becd042e10, 0x000001becdc945a0, 0x000001becdcab950, > > 0x000001becdf7e080 > > } > > Java Threads: ( => current thread ) > > =>0x000001beaa55be10 JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] > > 0x000001becd023240 JavaThread "Reference Handler" daemon [_thread_blocked, id=16356, stack(0x0000003933f00000,0x0000003934000000)] > > 0x000001becd023e00 JavaThread "Finalizer" daemon [_thread_blocked, id=6204, stack(0x0000003934000000,0x0000003934100000)] > > 0x000001becd0394b0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=972, stack(0x0000003934100000,0x0000003934200000)] > > 0x000001becd03a070 JavaThread "Attach Listener" daemon [_thread_blocked, id=2084, stack(0x0000003934200000,0x0000003934300000)] > > 0x000001becd03ea50 JavaThread "Service Thread" daemon [_thread_blocked, id=18128, stack(0x0000003934300000,0x0000003934400000)] > > 0x000001becd03f410 JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=3404, stack(0x0000003934400000,0x0000003934500000)] > > 0x000001becd0401b0 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=10160, stack(0x0000003934500000,0x0000003934600000)] > > 0x000001becd041400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=15728, stack(0x0000003934600000,0x0000003934700000)] > > 0x000001becd042e10 JavaThread "Sweeper thread" daemon [_thread_blocked, id=3932, stack(0x0000003934700000,0x0000003934800000)] > > 0x000001becdc945a0 JavaThread "Notification Thread" daemon [_thread_blocked, id=12368, stack(0x0000003934800000,0x0000003934900000)] > > 0x000001becdcab950 JavaThread "Common-Cleaner" daemon [_thread_blocked, id=15996, stack(0x0000003934a00000,0x0000003934b00000)] > > 0x000001becdf7e080 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=8236, stack(0x0000003934e00000,0x0000003934f00000)] > > Other Threads: > > 0x000001becd01c730 VMThread "VM Thread" [stack: 0x0000003933e00000,0x0000003933f00000] [id=8136] > > 0x000001becd00d9b0 WatcherThread [stack: 0x0000003934900000,0x0000003934a00000] [id=11228] > > 0x000001beaa5a9a40 GCTaskThread "GC Thread#0" [stack: 0x0000003933900000,0x0000003933a00000] [id=15472] > > 0x000001becde6f060 GCTaskThread "GC Thread#1" [stack: 0x0000003934b00000,0x0000003934c00000] [id=9408] > > 0x000001becde782a0 GCTaskThread "GC Thread#2" [stack: 0x0000003934c00000,0x0000003934d00000] [id=15952] > > 0x000001becde78560 GCTaskThread "GC Thread#3" [stack: 0x0000003934d00000,0x0000003934e00000] [id=17212] > > 0x000001bece9140e0 GCTaskThread "GC Thread#4" [stack: 0x0000003934f00000,0x0000003935000000] [id=13940] > > 0x000001bece914ea0 GCTaskThread "GC Thread#5" [stack: 0x0000003935000000,0x0000003935100000] [id=12744] > > 0x000001beaa5ba550 ConcurrentGCThread "G1 Main Marker" [stack: 0x0000003933a00000,0x0000003933b00000] [id=9236] > > 0x000001beaa5bbf70 ConcurrentGCThread "G1 Conc#0" [stack: 0x0000003933b00000,0x0000003933c00000] [id=17776] > > 0x000001beaa5e6a80 ConcurrentGCThread "G1 Refine#0" [stack: 0x0000003933c00000,0x0000003933d00000] [id=1088] > > 0x000001beaa5e84c0 ConcurrentGCThread "G1 Service" [stack: 0x0000003933d00000,0x0000003933e00000] [id=3248] > > Threads with active compile tasks: > > C2 CompilerThread0 608 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) > > VM state: not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap address: 0x0000000704400000, size: 4028 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 > > CDS archive(s) mapped at: [0x0000000800000000-0x0000000800bb0000-0x0000000800bb0000), size 12255232, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. > > Compressed class space mapped at: 0x0000000800c00000-0x0000000840c00000, reserved size: 1073741824 > > Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 > > GC Precious Log: > > CPUs: 8 total, 8 available > > Memory: 16107M > > Large Page Support: Disabled > > NUMA Support: Disabled > > Compressed Oops: Enabled (Zero based) > > Heap Region Size: 2M > > Heap Min Capacity: 8M > > Heap Initial Capacity: 8M > > Heap Max Capacity: 4028M > > Pre-touch: Disabled > > Parallel Workers: 8 > > Concurrent Workers: 2 > > Concurrent Refinement Workers: 8 > > Periodic GC: Disabled > > Heap: > > garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > Metaspace used 4346K, committed 5056K, reserved 1056768K > > class space used 589K, committed 896K, reserved 1048576K > > Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts), HC=humongous(continues), CS=collection set, F=free, OA=open archive, CA=closed archive, TAMS=top-at-mark-start (previous, next) > > | 0|0x0000000704400000, 0x00000007044e4e00, 0x0000000704600000| 44%| O| |TAMS 0x0000000704400000, 0x0000000704400000| Untracked > > | 1|0x0000000704600000, 0x0000000704600000, 0x0000000704800000| 0%| F| |TAMS 0x0000000704600000, 0x0000000704600000| Untracked > > | 2|0x0000000704800000, 0x00000007048fb810, 0x0000000704a00000| 49%| S|CS|TAMS 0x0000000704800000, 0x0000000704800000| Complete > > | 3|0x0000000704a00000, 0x0000000704bfa230, 0x0000000704c00000| 98%| E| |TAMS 0x0000000704a00000, 0x0000000704a00000| Complete > > Card table byte_map: [0x000001bec1900000,0x000001bec20e0000] _byte_map_base: 0x000001bebe0de000 > > Marking Bits (Prev, Next): (CMBitMap*) 0x000001beaa5aa060, (CMBitMap*) 0x000001beaa5aa0a0 > > Prev Bits: [0x000001bec28c0000, 0x000001bec67b0000) > > Next Bits: [0x000001bec67b0000, 0x000001beca6a0000) > > Polling page: 0x000001bea8380000 > > Metaspace: > > Usage: > > Non-class: 3.67 MB used. > > Class: 589.17 KB used. > > Both: 4.24 MB used. > > Virtual space: > > Non-class space: 8.00 MB reserved, 4.06 MB ( 51%) committed, 1 nodes. > > Class space: 1.00 GB reserved, 896.00 KB ( <1%) committed, 1 nodes. > > Both: 1.01 GB reserved, 4.94 MB ( <1%) committed. > > Chunk freelists: > > Non-Class: 2.55 MB > > Class: 2.96 MB > > Both: 5.51 MB > > MaxMetaspaceSize: unlimited > > CompressedClassSpaceSize: 1.00 GB > > Initial GC threshold: 21.00 MB > > Current GC threshold: 21.00 MB > > CDS: on > > MetaspaceReclaimPolicy: balanced > > - commit_granule_bytes: 65536. > - commit_granule_words: 8192. > - virtual_space_node_default_size: 1048576. > - enlarge_chunks_in_place: 1. > - new_chunks_are_fully_committed: 0. > - uncommit_free_chunks: 1. > - use_allocation_guard: 0. > - handle_deallocations: 1. > > Internal statistics: > > num_allocs_failed_limit: 0. > > num_arena_births: 990. > > num_arena_deaths: 0. > > num_vsnodes_births: 2. > > num_vsnodes_deaths: 0. > > num_space_committed: 79. > > num_space_uncommitted: 0. > > num_chunks_returned_to_freelist: 0. > > num_chunks_taken_from_freelist: 1166. > > num_chunk_merges: 0. > > num_chunk_splits: 758. > > num_chunks_enlarged: 370. > > num_purges: 0. > > CodeHeap 'non-profiled nmethods': size=120000Kb used=542Kb max_used=542Kb free=119458Kb > > bounds [0x000001beb98c0000, 0x000001beb9b30000, 0x000001bec0df0000] > > CodeHeap 'profiled nmethods': size=120000Kb used=1537Kb max_used=1537Kb free=118462Kb > > bounds [0x000001beb2390000, 0x000001beb2600000, 0x000001beb98c0000] > > CodeHeap 'non-nmethods': size=5760Kb used=1214Kb max_used=1246Kb free=4545Kb > > bounds [0x000001beb1df0000, 0x000001beb2060000, 0x000001beb2390000] > > total_blobs=1537 nmethods=1035 adapters=412 > > compilation: enabled > > stopped_count=0, restarted_count=0 > > full_count=0 > > Compilation events (20 events): > > Event: 0.590 Thread 0x000001becd041400 1020 3 java.lang.invoke.DirectMethodHandle:: (148 bytes) > > Event: 0.591 Thread 0x000001becd0401b0 nmethod 1019 0x000001beb9945710 code [0x000001beb9945880, 0x000001beb9945958] > > Event: 0.591 Thread 0x000001becd041400 nmethod 1020 0x000001beb2508510 code [0x000001beb25087c0, 0x000001beb2509748] > > Event: 0.591 Thread 0x000001becd0401b0 1021 4 jdk.internal.org.objectweb.asm.Frame::getLocal (46 bytes) > > Event: 0.591 Thread 0x000001becd0401b0 nmethod 1021 0x000001beb9946010 code [0x000001beb9946180, 0x000001beb9946258] > > Event: 0.592 Thread 0x000001becd041400 1024 3 java.lang.invoke.LambdaFormEditor$TransformKey::of (51 bytes) > > Event: 0.593 Thread 0x000001becd041400 nmethod 1024 0x000001beb2509c90 code [0x000001beb2509e80, 0x000001beb250a448] > > Event: 0.593 Thread 0x000001becd041400 1025 3 java.lang.invoke.LambdaFormEditor$TransformKey::packedBytes (39 bytes) > > Event: 0.593 Thread 0x000001becd041400 nmethod 1025 0x000001beb250a610 code [0x000001beb250a7a0, 0x000001beb250a8b8] > > Event: 0.593 Thread 0x000001becdf7e080 1028 4 java.lang.invoke.LambdaForm$BasicType::basicType (19 bytes) > > Event: 0.593 Thread 0x000001becd0401b0 1029 4 jdk.internal.org.objectweb.asm.Frame::pop (42 bytes) > > Event: 0.593 Thread 0x000001becd041400 1031 3 java.lang.invoke.MethodHandles::collectArguments (47 bytes) > > Event: 0.593 Thread 0x000001becd0401b0 nmethod 1029 0x000001beb9946910 code [0x000001beb9946a80, 0x000001beb9946b58] > > Event: 0.593 Thread 0x000001becd0401b0 1030 4 jdk.internal.org.objectweb.asm.Frame::merge (317 bytes) > > Event: 0.593 Thread 0x000001becd041400 nmethod 1031 0x000001beb250a990 code [0x000001beb250abc0, 0x000001beb250b3e8] > > Event: 0.593 Thread 0x000001becd041400 1032 3 java.lang.invoke.MethodHandles::collectArgumentsChecks (124 bytes) > > Event: 0.594 Thread 0x000001becd0401b0 nmethod 1030 0x000001beb9946c10 code [0x000001beb9946d80, 0x000001beb9946e78] > > Event: 0.594 Thread 0x000001becd0401b0 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) > > Event: 0.594 Thread 0x000001becd041400 nmethod 1032 0x000001beb250b790 code [0x000001beb250bb00, 0x000001beb250d2b8] > > Event: 0.594 Thread 0x000001becd041400 1033 3 java.lang.invoke.LambdaFormEditor::collectArgumentsForm (169 bytes) > > GC Heap History (10 events): > > Event: 0.086 GC heap before > > {Heap before GC invocations=0 (full 0): > > garbage-first heap total 8192K, used 2048K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 1 young (2048K), 0 survivors (0K) > > Metaspace used 1471K, committed 1664K, reserved 1056768K > > class space used 151K, committed 256K, reserved 1048576K > > } > > Event: 0.088 GC heap after > > {Heap after GC invocations=1 (full 0): > > garbage-first heap total 8192K, used 1168K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > Metaspace used 1471K, committed 1664K, reserved 1056768K > > class space used 151K, committed 256K, reserved 1048576K > > } > > Event: 0.135 GC heap before > > {Heap before GC invocations=1 (full 0): > > garbage-first heap total 8192K, used 3216K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > Metaspace used 2586K, committed 2880K, reserved 1056768K > > class space used 297K, committed 448K, reserved 1048576K > > } > > Event: 0.137 GC heap after > > {Heap after GC invocations=2 (full 0): > > garbage-first heap total 8192K, used 1270K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > Metaspace used 2586K, committed 2880K, reserved 1056768K > > class space used 297K, committed 448K, reserved 1048576K > > } > > Event: 0.165 GC heap before > > {Heap before GC invocations=2 (full 0): > > garbage-first heap total 8192K, used 3318K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > Metaspace used 2912K, committed 3328K, reserved 1056768K > > class space used 360K, committed 576K, reserved 1048576K > > } > > Event: 0.167 GC heap after > > {Heap after GC invocations=3 (full 0): > > garbage-first heap total 8192K, used 1460K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > Metaspace used 2912K, committed 3328K, reserved 1056768K > > class space used 360K, committed 576K, reserved 1048576K > > } > > Event: 0.366 GC heap before > > {Heap before GC invocations=3 (full 0): > > garbage-first heap total 8192K, used 3508K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > Metaspace used 3240K, committed 3712K, reserved 1056768K > > class space used 418K, committed 640K, reserved 1048576K > > } > > Event: 0.368 GC heap after > > {Heap after GC invocations=4 (full 0): > > garbage-first heap total 8192K, used 1629K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > Metaspace used 3240K, committed 3712K, reserved 1056768K > > class space used 418K, committed 640K, reserved 1048576K > > } > > Event: 0.570 GC heap before > > {Heap before GC invocations=4 (full 0): > > garbage-first heap total 8192K, used 3677K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > Metaspace used 4023K, committed 4608K, reserved 1056768K > > class space used 525K, committed 832K, reserved 1048576K > > } > > Event: 0.572 GC heap after > > {Heap after GC invocations=5 (full 0): > > garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > Metaspace used 4023K, committed 4608K, reserved 1056768K > > class space used 525K, committed 832K, reserved 1048576K > > } > > Deoptimization events (14 events): > > Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb98c3cac relative=0x000000000000020c > > Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb98c3cac method=java.lang.String.hashCode()I @ 42 c2 > > Event: 0.034 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb98c3cac sp=0x00000039338fe520 > > Event: 0.034 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe4b8 mode 2 > > Event: 0.122 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb23ab367 sp=0x00000039338fd790 > > Event: 0.122 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e46763 sp=0x00000039338fcbb0 mode 0 > > Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb990a7e0 relative=0x0000000000007740 > > Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb990a7e0 method=jdk.internal.org.objectweb.asm.Frame.execute(IILjdk/internal/org/objectweb/asm/Symbol;Ljdk/internal/org/objectweb/asm/SymbolTable;)V @ 1 c2 > > Event: 0.584 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb990a7e0 sp=0x00000039338fcef0 > > Event: 0.584 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fcea8 mode 2 > > Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffffcc fr.pc=0x000001beb9943df4 relative=0x0000000000000354 > > Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: reason=intrinsic_or_type_checked_inlining action=make_not_entrant pc=0x000001beb9943df4 method=java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; @ 35 c2 > > Event: 0.592 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb9943df4 sp=0x00000039338fe2b0 > > Event: 0.592 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe258 mode 2 > > Classes unloaded (0 events): > > No events > > Classes redefined (0 events): > > No events > > Internal exceptions (20 events): > > Event: 0.424 Thread 0x000001beaa55be10 Exception (0x0000000704b67fa8) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.566 Thread 0x000001beaa55be10 Exception (0x0000000704ba0908) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.572 Thread 0x000001beaa55be10 Exception (0x0000000704a048c8) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.574 Thread 0x000001beaa55be10 Exception (0x0000000704a359b8) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.576 Thread 0x000001beaa55be10 Exception (0x0000000704a69260) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.578 Thread 0x000001beaa55be10 Exception (0x0000000704a85548) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.579 Thread 0x000001beaa55be10 Exception (0x0000000704a9b548) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.581 Thread 0x000001beaa55be10 Exception (0x0000000704ac7840) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.582 Thread 0x000001beaa55be10 Exception (0x0000000704acada8) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b0f9a8) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b13248) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.588 Thread 0x000001beaa55be10 Exception (0x0000000704b66608) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b69ec0) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b72a48) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b765d8) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7a480) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7e200) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b99bd0) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b9d880) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Event: 0.593 Thread 0x000001beaa55be10 Exception (0x0000000704bd0ae8) > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Events (20 events): > > Event: 0.423 loading class java/io/DeleteOnExitHook done > > Event: 0.423 loading class java/io/DeleteOnExitHook$1 > > Event: 0.424 loading class java/io/DeleteOnExitHook$1 done > > Event: 0.550 Thread 0x000001beceebb670 Thread exited: 0x000001beceebb670 > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator done > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef done > > Event: 0.551 loading class java/util/stream/Streams$2 > > Event: 0.551 loading class java/util/stream/Streams$2 done > > Event: 0.570 Executing VM operation: G1CollectForAllocation > > Event: 0.572 Executing VM operation: G1CollectForAllocation done > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator done > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator done > > Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler > > Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler done > > Event: 0.594 loading class java/lang/invoke/MethodHandle$1 > > Event: 0.594 loading class java/lang/invoke/MethodHandle$1 done > > Dynamic libraries: > > 0x00007ff670d20000 - 0x00007ff670d28000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe > > 0x00007fff63110000 - 0x00007fff63305000 C:\Windows\SYSTEM32\ntdll.dll > > 0x00007fff61a00000 - 0x00007fff61abe000 C:\Windows\System32\KERNEL32.DLL > > 0x00007fff60960000 - 0x00007fff60c28000 C:\Windows\System32\KERNELBASE.dll > > 0x00007fff60830000 - 0x00007fff60930000 C:\Windows\System32\ucrtbase.dll > > 0x00007fff567c0000 - 0x00007fff567d8000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jli.dll > > 0x00007fff57310000 - 0x00007fff5732a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\VCRUNTIME140.dll > > 0x00007fff629b0000 - 0x00007fff62b51000 C:\Windows\System32\USER32.dll > > 0x00007fff60f30000 - 0x00007fff60f52000 C:\Windows\System32\win32u.dll > > 0x00007fff61ac0000 - 0x00007fff61aeb000 C:\Windows\System32\GDI32.dll > > 0x00007fff45910000 - 0x00007fff45baa000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\COMCTL32.dll > > 0x00007fff60c30000 - 0x00007fff60d3b000 C:\Windows\System32\gdi32full.dll > > 0x00007fff62fd0000 - 0x00007fff6306e000 C:\Windows\System32\msvcrt.dll > > 0x00007fff610c0000 - 0x00007fff6115d000 C:\Windows\System32\msvcp_win.dll > > 0x00007fff61160000 - 0x00007fff61190000 C:\Windows\System32\IMM32.DLL > > 0x00007fff5b580000 - 0x00007fff5b58c000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\vcruntime140_1.dll > > 0x00007fff44fa0000 - 0x00007fff4502d000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\msvcp140.dll > > 0x00007ffefad70000 - 0x00007ffefb920000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server\jvm.dll > > 0x00007fff61ef0000 - 0x00007fff61f9c000 C:\Windows\System32\ADVAPI32.dll > > 0x00007fff61cf0000 - 0x00007fff61d8b000 C:\Windows\System32\sechost.dll > > 0x00007fff62b60000 - 0x00007fff62c8a000 C:\Windows\System32\RPCRT4.dll > > 0x00007fff61ee0000 - 0x00007fff61ee8000 C:\Windows\System32\PSAPI.DLL > > 0x00007fff2dc20000 - 0x00007fff2dc29000 C:\Windows\SYSTEM32\WSOCK32.dll > > 0x00007fff54b80000 - 0x00007fff54b8a000 C:\Windows\SYSTEM32\VERSION.dll > > 0x00007fff518e0000 - 0x00007fff51907000 C:\Windows\SYSTEM32\WINMM.dll > > 0x00007fff61bd0000 - 0x00007fff61c3b000 C:\Windows\System32\WS2_32.dll > > 0x00007fff5f060000 - 0x00007fff5f072000 C:\Windows\SYSTEM32\kernel.appcore.dll > > 0x00007fff5b500000 - 0x00007fff5b50a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jimage.dll > > 0x00007fff5e430000 - 0x00007fff5e614000 C:\Windows\SYSTEM32\DBGHELP.DLL > > 0x00007fff45170000 - 0x00007fff4519c000 C:\Windows\SYSTEM32\dbgcore.DLL > > 0x00007fff60d40000 - 0x00007fff60dc3000 C:\Windows\System32\bcryptPrimitives.dll > > 0x00007fff44f70000 - 0x00007fff44f95000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\java.dll > > 0x00007fff612c0000 - 0x00007fff619ff000 C:\Windows\System32\SHELL32.dll > > 0x00007fff5e620000 - 0x00007fff5edb0000 C:\Windows\SYSTEM32\windows.storage.dll > > 0x00007fff62650000 - 0x00007fff629a5000 C:\Windows\System32\combase.dll > > 0x00007fff60280000 - 0x00007fff602ae000 C:\Windows\SYSTEM32\Wldp.dll > > 0x00007fff61c40000 - 0x00007fff61ced000 C:\Windows\System32\SHCORE.dll > > 0x00007fff62f70000 - 0x00007fff62fc5000 C:\Windows\System32\shlwapi.dll > > 0x00007fff60770000 - 0x00007fff6078f000 C:\Windows\SYSTEM32\profapi.dll > > 0x00007fff44f10000 - 0x00007fff44f29000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\net.dll > > 0x00007fff5ada0000 - 0x00007fff5aeac000 C:\Windows\SYSTEM32\WINHTTP.dll > > 0x00007fff5ffe0000 - 0x00007fff6004a000 C:\Windows\system32\mswsock.dll > > 0x00007fff28650000 - 0x00007fff28665000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\nio.dll > > 0x00007ffeda3b0000 - 0x00007ffede7d1000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\libclang.dll > > 0x00007fff62ea0000 - 0x00007fff62f6d000 C:\Windows\System32\OLEAUT32.dll > > 0x00007fff61190000 - 0x00007fff612ba000 C:\Windows\System32\ole32.dll > > 0x00007fff5dac0000 - 0x00007fff5db5e000 C:\Windows\system32\uxtheme.dll > > 0x00007fff61e30000 - 0x00007fff61ed9000 C:\Windows\System32\clbcatq.dll > > 0x00007fff601d0000 - 0x00007fff601e8000 C:\Windows\SYSTEM32\CRYPTSP.dll > > 0x00007fff5f8c0000 - 0x00007fff5f8f4000 C:\Windows\system32\rsaenh.dll > > 0x00007fff60930000 - 0x00007fff60957000 C:\Windows\System32\bcrypt.dll > > 0x00007fff60730000 - 0x00007fff6075e000 C:\Windows\SYSTEM32\USERENV.dll > > 0x00007fff601f0000 - 0x00007fff601fc000 C:\Windows\SYSTEM32\CRYPTBASE.dll > > 0x00007fff5fc80000 - 0x00007fff5fcbb000 C:\Windows\SYSTEM32\IPHLPAPI.DLL > > 0x00007fff62550000 - 0x00007fff62558000 C:\Windows\System32\NSI.dll > > 0x00007fff55080000 - 0x00007fff55097000 C:\Windows\SYSTEM32\dhcpcsvc6.DLL > > 0x00007fff55060000 - 0x00007fff5507d000 C:\Windows\SYSTEM32\dhcpcsvc.DLL > > 0x00007fff5fcd0000 - 0x00007fff5fd9b000 C:\Windows\SYSTEM32\DNSAPI.dll > > dbghelp: loaded successfully - version: 4.0.5 - missing functions: none > > symbol engine: initialized successfully - sym options: 0x614 - pdb path: .;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin;C:\Windows\SYSTEM32;C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server > > VM Arguments: > > jvm_args: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract > > java_command: jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h > > java_class_path (initial): > > Launcher Type: SUN_STANDARD > > [Global flags] > > intx CICompilerCount = 4 {product} {ergonomic} > > uint ConcGCThreads = 2 {product} {ergonomic} > > uint G1ConcRefinementThreads = 8 {product} {ergonomic} > > size_t G1HeapRegionSize = 2097152 {product} {ergonomic} > > uintx GCDrainStackTargetSize = 64 {product} {ergonomic} > > size_t InitialHeapSize = 8388608 {product} {command line} > > size_t MarkStackSize = 4194304 {product} {ergonomic} > > size_t MaxHeapSize = 4223664128 {product} {ergonomic} > > size_t MaxNewSize = 2533359616 {product} {ergonomic} > > size_t MinHeapDeltaBytes = 2097152 {product} {ergonomic} > > size_t MinHeapSize = 8388608 {product} {command line} > > uintx NonNMethodCodeHeapSize = 5839372 {pd product} {ergonomic} > > uintx NonProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} > > uintx ProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} > > uintx ReservedCodeCacheSize = 251658240 {pd product} {ergonomic} > > bool SegmentedCodeCache = true {product} {ergonomic} > > size_t SoftMaxHeapSize = 4223664128 {manageable} {ergonomic} > > bool UseCompressedClassPointers = true {product lp64_product} {ergonomic} > > bool UseCompressedOops = true {product lp64_product} {ergonomic} > > bool UseG1GC = true {product} {ergonomic} > > bool UseLargePagesIndividualAllocation = false {pd product} {ergonomic} > > Logging: > > Log output configuration: > > #0: stdout all=warning uptime,level,tags > > #1: stderr all=off uptime,level,tags > > Environment Variables: > > JAVA_HOME=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 > > PATH=C:\Program Files\Zulu\zulu-11\bin\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Program Files (x86)\apache-ant-1.9.16\bin;C:\Program Files\CMake\bin;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\7-Zip;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\gawk-3.1.6-1-bin\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin;C:\Users\Martin\AppData\Local\Microsoft\WindowsApps;C:\Users\Martin\AppData\Local\atom\bin;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Users\Martin\.dotnet\tools > > USERNAME=Martin > > OS=Windows_NT > > PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 140 Stepping 1, GenuineIntel > > --------------- S Y S T E M --------------- > > OS: > > Windows 10 , 64 bit Build 19041 (10.0.19041.1348) > > OS uptime: 0 days 4:15 hours > > Hyper-V role detected > > CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 6 model 140 stepping 1 microcode 0x86, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, avx512f, avx512dq, avx512cd, avx512bw, avx512vl, sha, fma, vzeroupper, avx512_vpopcntdq, avx512_vpclmulqdq, avx512_vaes, avx512_vnni, clflush, clflushopt, clwb, avx512_vbmi2, avx512_vbmi, hv > > Memory: 4k page, system-wide physical 16107M (6064M free) > > TotalPageFile size 20971M (AvailPageFile size 8500M) > > current process WorkingSet (physical memory assigned to process): 136M, peak: 147M > > current process commit charge ("private bytes"): 177M, peak: 191M > > vm_info: OpenJDK 64-Bit Server VM (17-panama+3-167) for windows-amd64 JRE (17-panama+3-167), built on May 18 2021 13:10:19 by "mach5one" with MS VC++ 16.8 (VS2019) > > END. > > Sent with ProtonMail Secure Email. > > ??????? Original Message ??????? > > Le vendredi 12 novembre 2021 ? 15:47, Martin Pernollet martin.pernollet at protonmail.com a ?crit : > > > Thanks Jon, > > > > MinGW did not create a GL.dll file but rather libfreeglut.dll so I changed to > > > > public class glut_h extends glut_h_3 { > > > > static { > > > > System.loadLibrary("libfreeglut"); > > > > But it still fails, this time due to unresolved dependencies. Dependency Walker reveals tons of unreachable DLL (see screenshot). > > > > This failed attempt is documented here https://github.com/jzy3d/panama-gl/issues/11 > > > > I'll follow your suggestion and update documentation and notify you once I got it working. > > > > ??????? Original Message ??????? > > > > Le vendredi 12 novembre 2021 ? 15:17, Jorn Vernee jorn.vernee at oracle.com a ?crit : > > > > > Hi Martin, > > > > > > Thanks for testing this! > > > > > > The UnsatisfiedLinkError is not from code looking for a header file, > > > > > > it's from looking for a library/.dll file named GL.dll. On Windows > > > > > > though, freeglut needs the opengl libraries that come bundled with > > > > > > Windows (found in C:\Windows\System32), named opengl32 and glu32. The > > > > > > script should already add -l flags for those. > > > > > > WRT the jextract error you see. > > > > > > I have not tried to run the sample with freeglut installed through MingW > > > > > > yet. I instead used the freeglut package for MSVC here: > > > > > > https://www.transmissionzero.co.uk/software/freeglut-devel/ extracted > > > > > > that in some folder, and the pointed freeglutPath at that folder. > > > > > > Note that jextract is using clang underneath to do the parsing. I know > > > > > > clang works pretty well with MSVC/Windows SDK header files, but I'm > > > > > > guessing it can not understand the MingW headers, looking at your error. > > > > > > I think it's having problems with __MINGW_NOTHROW and > > > > > > __MINGW_ATTRIB_NORETURN, which look like compiler builtins. > > > > > > I'd suggest trying the freeglut package I linked to instead, together > > > > > > with the Windows SDK headers (which clang should find automatically), > > > > > > and taking MingW headers out of the equation for now. We should probably > > > > > > create a README for that sample to include instructions on how to get > > > > > > freeglut. > > > > > > Note that on top of that, you will also have to change Teapot.java to > > > > > > account for a change in parameter names resulting in slightly different > > > > > > code being generated by jextract [1]. > > > > > > HTH, > > > > > > Jorn > > > > > > [1] : > > > > > > diff --git a/opengl/Teapot.java b/opengl/Teapot.java > > > > > > index 22d1f44..d5eb786 100644 > > > > > > --- a/opengl/Teapot.java > > > > > > +++ b/opengl/Teapot.java > > > > > > @@ -79,8 +79,8 @@ public class Teapot { > > > > > > glutInitWindowSize(500, 500); > > > > > > glutCreateWindow(allocator.allocateUtf8String("Hello Panama!")); > > > > > > var teapot = new Teapot(allocator); > > > > > > -??????????? var displayStub = > > > > > > glutDisplayFunc$func.allocate(teapot::display, scope); > > > > > > -??????????? var idleStub = glutIdleFunc$func.allocate(teapot::onIdle, > > > > > > scope); > > > > > > +??????????? var displayStub = > > > > > > glutDisplayFunc$callback.allocate(teapot::display, scope); > > > > > > +??????????? var idleStub = > > > > > > glutIdleFunc$callback.allocate(teapot::onIdle, scope); > > > > > > glutDisplayFunc(displayStub); > > > > > > glutIdleFunc(idleStub); > > > > > > glutMainLoop(); > > > > > > On 12/11/2021 13:01, Martin Pernollet wrote: > > > > > > > Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows : > > > > > > > > public class glut_h extends glut_h_3 { > > > > > > > > static { > > > > > > > > System.loadLibrary("GL"); > > > > > > > > System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT"); > > > > > > > > } > > > > > > > > while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW. > > > > > > > > Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir. > > > > > > > > So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception : > > > > > > > > PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1 > > > > > > > > [...] > > > > > > > > freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32 > > > > > > > > WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract > > > > > > > > C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator > > > > > > > > ERROR: jextract exited with non-zero exit code: 3 > > > > > > > > Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 : > > > > > > > > 358: #ifndef _CRT_TERMINATE_DEFINED > > > > > > > > 359: #define _CRT_TERMINATE_DEFINED > > > > > > > > 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; > > > > > > > > 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN; > > > > > > > > I should mention that > > > > > > > > - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct. > > > > - I verified GCC and G++ are callable from Powershell > > > > - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself. > > > > > > > > Is this stdlib error something some of you already faced? How did you fix? > > > > > > > > Thanks! > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > ??????? Original Message ??????? > > > > > > > > Le lundi 18 octobre 2021 ? 11:29, Rado Smogura mail at smogura.eu a ?crit : > > > > > > > > > Hi Martin, > > > > > > > > > > Let me answer the last questions about JExtract and .h files for every > > > > > > > > > > platform. > > > > > > > > > > It may be needed to do separate bindings, unless you can prove > > > > > > > > > > otherwise. The specifications provides .h files and names, but may not > > > > > > > > > > be clear if, > > > > > > > > > > - given name is variable, or define > > > > > > > > > > - values set to const / variable > > > > > > > > > > - expr() is method or define > > > > > > > > > > There was one experiment with POSIX, where even so standard things like > > > > > > > > > > net may differ on values assigned to DEFINED between Linux & OSX. > > > > > > > > > > Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other, > > > > > > > > > > and this values will be "inlined" into extracted code. > > > > > > > > > > However how exactly is with OpenGL I don't know. > > > > > > > > > > Kind regards, > > > > > > > > > > Rado > > > > > > > > > > On 17.10.2021 15:20, Martin Pernollet wrote: > > > > > > > > > > > > > > > > Report about more intensive use of foreign function API > > > > > > > > > > > > I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn?t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow : > > > > > > > > > > > > void onIdle() { > > > > > > > > > > > > throw new IllegalArgumentException("Teapot does not support coffee"); > > > > > > > > > > > > } > > > > > > > > > > > > My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412. > > > > > > > > > > > > I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before. > > > > > > > > > > > > Integration in an AWT Canvas > > > > > > > > > > > > Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU. > > > > > > > > > > > > It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc. > > > > > > > > > > > > I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL. > > > > > > > > > > > > Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) > > > > > > > > > > > > I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way). > > > > > > > > > > > > More practical questions about JExtract > > > > > > > > > > > > I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case. > > > > > > > > > > > > Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM? > > > > > > > > > > > > Thanks for reading! > > > > > > > > > > > > Martin > > > > > > > > > > > > [0] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8bHkQ00p$ > > > > > > > > > > > > [1] https://urldefense.com/v3/https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8ROseeEa$ > > > > > > > > > > > > [2] https://urldefense.com/v3/https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8WkFrawU$ From jorn.vernee at oracle.com Fri Nov 12 15:25:35 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 12 Nov 2021 16:25:35 +0100 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> Message-ID: Hi Martin, This looks like a case of: https://github.com/openjdk/jdk17/pull/35 Are you using the panama snapshot from jdk.java.net? That snapshot doesn't contain the fix AFAIK. The samples are also made for the latest panama-foreign API, so they won't work with the snapshot (at least not out of the box). I think the only solution to the crash is to build the panama-foreign/foreign-jextract branch yourself. Sorry, Jorn On 12/11/2021 16:09, Martin Pernollet wrote: > When I now try with the precompiled freeglut you suggest I got a jextract crash. My exact command was > > C:\Program" "Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe ` > -I "C:\Users\Martin\Dev\jzy3d\external\freeglut\include" ` > "-l" opengl32 ` > "-l" glu32 ` > "-l" freeglut ` > "-t" "opengl" ` > "--" ` > "C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h" > > > And the core dump file says > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (codeBuffer.cpp:972), pid=8664, tid=17112 > # guarantee(sect->end() <= tend) failed: sanity > # > # JRE version: OpenJDK Runtime Environment (17.0+3) (build 17-panama+3-167) > # Java VM: OpenJDK 64-Bit Server VM (17-panama+3-167, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) > # No core dump will be written. Minidumps are not enabled by default on client versions of Windows > # > # If you would like to submit a bug report, please visit: > # https://urldefense.com/v3/__https://bugreport.java.com/bugreport/crash.jsp__;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI5KK9Rju$ > # > > --------------- S U M M A R Y ------------ > > Command Line: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h > > Host: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 8 cores, 15G, Windows 10 , 64 bit Build 19041 (10.0.19041.1348) > Time: Fri Nov 12 16:06:50 2021 Europe de l , 64 bit Build 19041 (10.0.19041.1348) elapsed time: 0.603555 seconds (0d 0h 0m 0s) > > --------------- T H R E A D --------------- > > Current thread (0x000001beaa55be10): JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] > > Stack: [0x0000003933800000,0x0000003933900000] > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [jvm.dll+0x668f4a] > V [jvm.dll+0x7c69a9] > V [jvm.dll+0x7c814e] > V [jvm.dll+0x7c8757] > V [jvm.dll+0x23ec9c] > V [jvm.dll+0x1f92d0] > V [jvm.dll+0x795431] > V [jvm.dll+0x792fa9] > C 0x000001beb1dfd661 > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j jdk.internal.foreign.abi.ProgrammableUpcallHandler.allocateOptimizedUpcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/ABIDescriptor;Ljdk/internal/foreign/abi/ProgrammableUpcallHandler$CallRegs;)J+0 jdk.incubator.foreign at 17-panama > j jdk.internal.foreign.abi.ProgrammableUpcallHandler.make(Ljdk/internal/foreign/abi/ABIDescriptor;Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/CallingSequence;)Ljdk/internal/foreign/abi/UpcallHandler;+380 jdk.incubator.foreign at 17-panama > j jdk.internal.foreign.abi.x64.windows.CallArranger.arrangeUpcall(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;Ljdk/incubator/foreign/FunctionDescriptor;)Ljdk/internal/foreign/abi/UpcallHandler;+28 jdk.incubator.foreign at 17-panama > j jdk.internal.foreign.abi.x64.windows.Windowsx64Linker.upcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/incubator/foreign/FunctionDescriptor;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+35 jdk.incubator.foreign at 17-panama > j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+34 jdk.incubator.jextract at 17-panama > j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;)Ljdk/incubator/foreign/MemoryAddress;+7 jdk.incubator.jextract at 17-panama > j jdk.internal.clang.libclang.CXCursorVisitor.allocate(Ljdk/internal/clang/libclang/CXCursorVisitor;)Ljdk/incubator/foreign/MemoryAddress;+8 jdk.incubator.jextract at 17-panama > j jdk.internal.clang.Cursor$CursorChildren.()V+15 jdk.incubator.jextract at 17-panama > v ~StubRoutines::call_stub > j jdk.internal.clang.Cursor.children()Ljava/util/stream/Stream;+1 jdk.incubator.jextract at 17-panama > j jdk.internal.jextract.impl.Parser.parse(Ljava/nio/file/Path;Ljava/util/Collection;)Ljdk/incubator/jextract/Declaration$Scoped;+66 jdk.incubator.jextract at 17-panama > j jdk.incubator.jextract.JextractTool.parse(Ljava/util/List;[Ljava/lang/String;)Ljdk/incubator/jextract/Declaration$Scoped;+55 jdk.incubator.jextract at 17-panama > j jdk.incubator.jextract.JextractTool.run([Ljava/lang/String;)I+904 jdk.incubator.jextract at 17-panama > j jdk.incubator.jextract.JextractTool.main([Ljava/lang/String;)V+46 jdk.incubator.jextract at 17-panama > v ~StubRoutines::call_stub > > --------------- P R O C E S S --------------- > > Threads class SMR info: > _java_thread_list=0x000001bece7196e0, length=13, elements={ > 0x000001beaa55be10, 0x000001becd023240, 0x000001becd023e00, 0x000001becd0394b0, > 0x000001becd03a070, 0x000001becd03ea50, 0x000001becd03f410, 0x000001becd0401b0, > 0x000001becd041400, 0x000001becd042e10, 0x000001becdc945a0, 0x000001becdcab950, > 0x000001becdf7e080 > } > > Java Threads: ( => current thread ) > =>0x000001beaa55be10 JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] > 0x000001becd023240 JavaThread "Reference Handler" daemon [_thread_blocked, id=16356, stack(0x0000003933f00000,0x0000003934000000)] > 0x000001becd023e00 JavaThread "Finalizer" daemon [_thread_blocked, id=6204, stack(0x0000003934000000,0x0000003934100000)] > 0x000001becd0394b0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=972, stack(0x0000003934100000,0x0000003934200000)] > 0x000001becd03a070 JavaThread "Attach Listener" daemon [_thread_blocked, id=2084, stack(0x0000003934200000,0x0000003934300000)] > 0x000001becd03ea50 JavaThread "Service Thread" daemon [_thread_blocked, id=18128, stack(0x0000003934300000,0x0000003934400000)] > 0x000001becd03f410 JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=3404, stack(0x0000003934400000,0x0000003934500000)] > 0x000001becd0401b0 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=10160, stack(0x0000003934500000,0x0000003934600000)] > 0x000001becd041400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=15728, stack(0x0000003934600000,0x0000003934700000)] > 0x000001becd042e10 JavaThread "Sweeper thread" daemon [_thread_blocked, id=3932, stack(0x0000003934700000,0x0000003934800000)] > 0x000001becdc945a0 JavaThread "Notification Thread" daemon [_thread_blocked, id=12368, stack(0x0000003934800000,0x0000003934900000)] > 0x000001becdcab950 JavaThread "Common-Cleaner" daemon [_thread_blocked, id=15996, stack(0x0000003934a00000,0x0000003934b00000)] > 0x000001becdf7e080 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=8236, stack(0x0000003934e00000,0x0000003934f00000)] > > Other Threads: > 0x000001becd01c730 VMThread "VM Thread" [stack: 0x0000003933e00000,0x0000003933f00000] [id=8136] > 0x000001becd00d9b0 WatcherThread [stack: 0x0000003934900000,0x0000003934a00000] [id=11228] > 0x000001beaa5a9a40 GCTaskThread "GC Thread#0" [stack: 0x0000003933900000,0x0000003933a00000] [id=15472] > 0x000001becde6f060 GCTaskThread "GC Thread#1" [stack: 0x0000003934b00000,0x0000003934c00000] [id=9408] > 0x000001becde782a0 GCTaskThread "GC Thread#2" [stack: 0x0000003934c00000,0x0000003934d00000] [id=15952] > 0x000001becde78560 GCTaskThread "GC Thread#3" [stack: 0x0000003934d00000,0x0000003934e00000] [id=17212] > 0x000001bece9140e0 GCTaskThread "GC Thread#4" [stack: 0x0000003934f00000,0x0000003935000000] [id=13940] > 0x000001bece914ea0 GCTaskThread "GC Thread#5" [stack: 0x0000003935000000,0x0000003935100000] [id=12744] > 0x000001beaa5ba550 ConcurrentGCThread "G1 Main Marker" [stack: 0x0000003933a00000,0x0000003933b00000] [id=9236] > 0x000001beaa5bbf70 ConcurrentGCThread "G1 Conc#0" [stack: 0x0000003933b00000,0x0000003933c00000] [id=17776] > 0x000001beaa5e6a80 ConcurrentGCThread "G1 Refine#0" [stack: 0x0000003933c00000,0x0000003933d00000] [id=1088] > 0x000001beaa5e84c0 ConcurrentGCThread "G1 Service" [stack: 0x0000003933d00000,0x0000003933e00000] [id=3248] > > Threads with active compile tasks: > C2 CompilerThread0 608 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) > > VM state: not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap address: 0x0000000704400000, size: 4028 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 > > CDS archive(s) mapped at: [0x0000000800000000-0x0000000800bb0000-0x0000000800bb0000), size 12255232, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. > Compressed class space mapped at: 0x0000000800c00000-0x0000000840c00000, reserved size: 1073741824 > Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 > > GC Precious Log: > CPUs: 8 total, 8 available > Memory: 16107M > Large Page Support: Disabled > NUMA Support: Disabled > Compressed Oops: Enabled (Zero based) > Heap Region Size: 2M > Heap Min Capacity: 8M > Heap Initial Capacity: 8M > Heap Max Capacity: 4028M > Pre-touch: Disabled > Parallel Workers: 8 > Concurrent Workers: 2 > Concurrent Refinement Workers: 8 > Periodic GC: Disabled > > Heap: > garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 2 young (4096K), 1 survivors (2048K) > Metaspace used 4346K, committed 5056K, reserved 1056768K > class space used 589K, committed 896K, reserved 1048576K > > Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts), HC=humongous(continues), CS=collection set, F=free, OA=open archive, CA=closed archive, TAMS=top-at-mark-start (previous, next) > | 0|0x0000000704400000, 0x00000007044e4e00, 0x0000000704600000| 44%| O| |TAMS 0x0000000704400000, 0x0000000704400000| Untracked > | 1|0x0000000704600000, 0x0000000704600000, 0x0000000704800000| 0%| F| |TAMS 0x0000000704600000, 0x0000000704600000| Untracked > | 2|0x0000000704800000, 0x00000007048fb810, 0x0000000704a00000| 49%| S|CS|TAMS 0x0000000704800000, 0x0000000704800000| Complete > | 3|0x0000000704a00000, 0x0000000704bfa230, 0x0000000704c00000| 98%| E| |TAMS 0x0000000704a00000, 0x0000000704a00000| Complete > > Card table byte_map: [0x000001bec1900000,0x000001bec20e0000] _byte_map_base: 0x000001bebe0de000 > > Marking Bits (Prev, Next): (CMBitMap*) 0x000001beaa5aa060, (CMBitMap*) 0x000001beaa5aa0a0 > Prev Bits: [0x000001bec28c0000, 0x000001bec67b0000) > Next Bits: [0x000001bec67b0000, 0x000001beca6a0000) > > Polling page: 0x000001bea8380000 > > Metaspace: > > Usage: > Non-class: 3.67 MB used. > Class: 589.17 KB used. > Both: 4.24 MB used. > > Virtual space: > Non-class space: 8.00 MB reserved, 4.06 MB ( 51%) committed, 1 nodes. > Class space: 1.00 GB reserved, 896.00 KB ( <1%) committed, 1 nodes. > Both: 1.01 GB reserved, 4.94 MB ( <1%) committed. > > Chunk freelists: > Non-Class: 2.55 MB > Class: 2.96 MB > Both: 5.51 MB > > MaxMetaspaceSize: unlimited > CompressedClassSpaceSize: 1.00 GB > Initial GC threshold: 21.00 MB > Current GC threshold: 21.00 MB > CDS: on > MetaspaceReclaimPolicy: balanced > - commit_granule_bytes: 65536. > - commit_granule_words: 8192. > - virtual_space_node_default_size: 1048576. > - enlarge_chunks_in_place: 1. > - new_chunks_are_fully_committed: 0. > - uncommit_free_chunks: 1. > - use_allocation_guard: 0. > - handle_deallocations: 1. > > > Internal statistics: > > num_allocs_failed_limit: 0. > num_arena_births: 990. > num_arena_deaths: 0. > num_vsnodes_births: 2. > num_vsnodes_deaths: 0. > num_space_committed: 79. > num_space_uncommitted: 0. > num_chunks_returned_to_freelist: 0. > num_chunks_taken_from_freelist: 1166. > num_chunk_merges: 0. > num_chunk_splits: 758. > num_chunks_enlarged: 370. > num_purges: 0. > > CodeHeap 'non-profiled nmethods': size=120000Kb used=542Kb max_used=542Kb free=119458Kb > bounds [0x000001beb98c0000, 0x000001beb9b30000, 0x000001bec0df0000] > CodeHeap 'profiled nmethods': size=120000Kb used=1537Kb max_used=1537Kb free=118462Kb > bounds [0x000001beb2390000, 0x000001beb2600000, 0x000001beb98c0000] > CodeHeap 'non-nmethods': size=5760Kb used=1214Kb max_used=1246Kb free=4545Kb > bounds [0x000001beb1df0000, 0x000001beb2060000, 0x000001beb2390000] > total_blobs=1537 nmethods=1035 adapters=412 > compilation: enabled > stopped_count=0, restarted_count=0 > full_count=0 > > Compilation events (20 events): > Event: 0.590 Thread 0x000001becd041400 1020 3 java.lang.invoke.DirectMethodHandle:: (148 bytes) > Event: 0.591 Thread 0x000001becd0401b0 nmethod 1019 0x000001beb9945710 code [0x000001beb9945880, 0x000001beb9945958] > Event: 0.591 Thread 0x000001becd041400 nmethod 1020 0x000001beb2508510 code [0x000001beb25087c0, 0x000001beb2509748] > Event: 0.591 Thread 0x000001becd0401b0 1021 4 jdk.internal.org.objectweb.asm.Frame::getLocal (46 bytes) > Event: 0.591 Thread 0x000001becd0401b0 nmethod 1021 0x000001beb9946010 code [0x000001beb9946180, 0x000001beb9946258] > Event: 0.592 Thread 0x000001becd041400 1024 3 java.lang.invoke.LambdaFormEditor$TransformKey::of (51 bytes) > Event: 0.593 Thread 0x000001becd041400 nmethod 1024 0x000001beb2509c90 code [0x000001beb2509e80, 0x000001beb250a448] > Event: 0.593 Thread 0x000001becd041400 1025 3 java.lang.invoke.LambdaFormEditor$TransformKey::packedBytes (39 bytes) > Event: 0.593 Thread 0x000001becd041400 nmethod 1025 0x000001beb250a610 code [0x000001beb250a7a0, 0x000001beb250a8b8] > Event: 0.593 Thread 0x000001becdf7e080 1028 4 java.lang.invoke.LambdaForm$BasicType::basicType (19 bytes) > Event: 0.593 Thread 0x000001becd0401b0 1029 4 jdk.internal.org.objectweb.asm.Frame::pop (42 bytes) > Event: 0.593 Thread 0x000001becd041400 1031 3 java.lang.invoke.MethodHandles::collectArguments (47 bytes) > Event: 0.593 Thread 0x000001becd0401b0 nmethod 1029 0x000001beb9946910 code [0x000001beb9946a80, 0x000001beb9946b58] > Event: 0.593 Thread 0x000001becd0401b0 1030 4 jdk.internal.org.objectweb.asm.Frame::merge (317 bytes) > Event: 0.593 Thread 0x000001becd041400 nmethod 1031 0x000001beb250a990 code [0x000001beb250abc0, 0x000001beb250b3e8] > Event: 0.593 Thread 0x000001becd041400 1032 3 java.lang.invoke.MethodHandles::collectArgumentsChecks (124 bytes) > Event: 0.594 Thread 0x000001becd0401b0 nmethod 1030 0x000001beb9946c10 code [0x000001beb9946d80, 0x000001beb9946e78] > Event: 0.594 Thread 0x000001becd0401b0 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) > Event: 0.594 Thread 0x000001becd041400 nmethod 1032 0x000001beb250b790 code [0x000001beb250bb00, 0x000001beb250d2b8] > Event: 0.594 Thread 0x000001becd041400 1033 3 java.lang.invoke.LambdaFormEditor::collectArgumentsForm (169 bytes) > > GC Heap History (10 events): > Event: 0.086 GC heap before > {Heap before GC invocations=0 (full 0): > garbage-first heap total 8192K, used 2048K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 1 young (2048K), 0 survivors (0K) > Metaspace used 1471K, committed 1664K, reserved 1056768K > class space used 151K, committed 256K, reserved 1048576K > } > Event: 0.088 GC heap after > {Heap after GC invocations=1 (full 0): > garbage-first heap total 8192K, used 1168K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 1 young (2048K), 1 survivors (2048K) > Metaspace used 1471K, committed 1664K, reserved 1056768K > class space used 151K, committed 256K, reserved 1048576K > } > Event: 0.135 GC heap before > {Heap before GC invocations=1 (full 0): > garbage-first heap total 8192K, used 3216K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 2 young (4096K), 1 survivors (2048K) > Metaspace used 2586K, committed 2880K, reserved 1056768K > class space used 297K, committed 448K, reserved 1048576K > } > Event: 0.137 GC heap after > {Heap after GC invocations=2 (full 0): > garbage-first heap total 8192K, used 1270K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 1 young (2048K), 1 survivors (2048K) > Metaspace used 2586K, committed 2880K, reserved 1056768K > class space used 297K, committed 448K, reserved 1048576K > } > Event: 0.165 GC heap before > {Heap before GC invocations=2 (full 0): > garbage-first heap total 8192K, used 3318K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 2 young (4096K), 1 survivors (2048K) > Metaspace used 2912K, committed 3328K, reserved 1056768K > class space used 360K, committed 576K, reserved 1048576K > } > Event: 0.167 GC heap after > {Heap after GC invocations=3 (full 0): > garbage-first heap total 8192K, used 1460K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 1 young (2048K), 1 survivors (2048K) > Metaspace used 2912K, committed 3328K, reserved 1056768K > class space used 360K, committed 576K, reserved 1048576K > } > Event: 0.366 GC heap before > {Heap before GC invocations=3 (full 0): > garbage-first heap total 8192K, used 3508K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 2 young (4096K), 1 survivors (2048K) > Metaspace used 3240K, committed 3712K, reserved 1056768K > class space used 418K, committed 640K, reserved 1048576K > } > Event: 0.368 GC heap after > {Heap after GC invocations=4 (full 0): > garbage-first heap total 8192K, used 1629K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 1 young (2048K), 1 survivors (2048K) > Metaspace used 3240K, committed 3712K, reserved 1056768K > class space used 418K, committed 640K, reserved 1048576K > } > Event: 0.570 GC heap before > {Heap before GC invocations=4 (full 0): > garbage-first heap total 8192K, used 3677K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 2 young (4096K), 1 survivors (2048K) > Metaspace used 4023K, committed 4608K, reserved 1056768K > class space used 525K, committed 832K, reserved 1048576K > } > Event: 0.572 GC heap after > {Heap after GC invocations=5 (full 0): > garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) > region size 2048K, 1 young (2048K), 1 survivors (2048K) > Metaspace used 4023K, committed 4608K, reserved 1056768K > class space used 525K, committed 832K, reserved 1048576K > } > > Deoptimization events (14 events): > Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb98c3cac relative=0x000000000000020c > Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb98c3cac method=java.lang.String.hashCode()I @ 42 c2 > Event: 0.034 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb98c3cac sp=0x00000039338fe520 > Event: 0.034 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe4b8 mode 2 > Event: 0.122 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb23ab367 sp=0x00000039338fd790 > Event: 0.122 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e46763 sp=0x00000039338fcbb0 mode 0 > Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb990a7e0 relative=0x0000000000007740 > Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb990a7e0 method=jdk.internal.org.objectweb.asm.Frame.execute(IILjdk/internal/org/objectweb/asm/Symbol;Ljdk/internal/org/objectweb/asm/SymbolTable;)V @ 1 c2 > Event: 0.584 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb990a7e0 sp=0x00000039338fcef0 > Event: 0.584 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fcea8 mode 2 > Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffffcc fr.pc=0x000001beb9943df4 relative=0x0000000000000354 > Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: reason=intrinsic_or_type_checked_inlining action=make_not_entrant pc=0x000001beb9943df4 method=java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; @ 35 c2 > Event: 0.592 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb9943df4 sp=0x00000039338fe2b0 > Event: 0.592 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe258 mode 2 > > Classes unloaded (0 events): > No events > > Classes redefined (0 events): > No events > > Internal exceptions (20 events): > Event: 0.424 Thread 0x000001beaa55be10 Exception (0x0000000704b67fa8) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.566 Thread 0x000001beaa55be10 Exception (0x0000000704ba0908) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.572 Thread 0x000001beaa55be10 Exception (0x0000000704a048c8) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.574 Thread 0x000001beaa55be10 Exception (0x0000000704a359b8) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.576 Thread 0x000001beaa55be10 Exception (0x0000000704a69260) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.578 Thread 0x000001beaa55be10 Exception (0x0000000704a85548) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.579 Thread 0x000001beaa55be10 Exception (0x0000000704a9b548) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.581 Thread 0x000001beaa55be10 Exception (0x0000000704ac7840) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.582 Thread 0x000001beaa55be10 Exception (0x0000000704acada8) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b0f9a8) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b13248) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.588 Thread 0x000001beaa55be10 Exception (0x0000000704b66608) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b69ec0) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b72a48) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b765d8) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7a480) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7e200) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b99bd0) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b9d880) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > Event: 0.593 Thread 0x000001beaa55be10 Exception (0x0000000704bd0ae8) > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > Events (20 events): > Event: 0.423 loading class java/io/DeleteOnExitHook done > Event: 0.423 loading class java/io/DeleteOnExitHook$1 > Event: 0.424 loading class java/io/DeleteOnExitHook$1 done > Event: 0.550 Thread 0x000001beceebb670 Thread exited: 0x000001beceebb670 > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator done > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef done > Event: 0.551 loading class java/util/stream/Streams$2 > Event: 0.551 loading class java/util/stream/Streams$2 done > Event: 0.570 Executing VM operation: G1CollectForAllocation > Event: 0.572 Executing VM operation: G1CollectForAllocation done > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator done > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator done > Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler > Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler done > Event: 0.594 loading class java/lang/invoke/MethodHandle$1 > Event: 0.594 loading class java/lang/invoke/MethodHandle$1 done > > > Dynamic libraries: > 0x00007ff670d20000 - 0x00007ff670d28000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe > 0x00007fff63110000 - 0x00007fff63305000 C:\Windows\SYSTEM32\ntdll.dll > 0x00007fff61a00000 - 0x00007fff61abe000 C:\Windows\System32\KERNEL32.DLL > 0x00007fff60960000 - 0x00007fff60c28000 C:\Windows\System32\KERNELBASE.dll > 0x00007fff60830000 - 0x00007fff60930000 C:\Windows\System32\ucrtbase.dll > 0x00007fff567c0000 - 0x00007fff567d8000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jli.dll > 0x00007fff57310000 - 0x00007fff5732a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\VCRUNTIME140.dll > 0x00007fff629b0000 - 0x00007fff62b51000 C:\Windows\System32\USER32.dll > 0x00007fff60f30000 - 0x00007fff60f52000 C:\Windows\System32\win32u.dll > 0x00007fff61ac0000 - 0x00007fff61aeb000 C:\Windows\System32\GDI32.dll > 0x00007fff45910000 - 0x00007fff45baa000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\COMCTL32.dll > 0x00007fff60c30000 - 0x00007fff60d3b000 C:\Windows\System32\gdi32full.dll > 0x00007fff62fd0000 - 0x00007fff6306e000 C:\Windows\System32\msvcrt.dll > 0x00007fff610c0000 - 0x00007fff6115d000 C:\Windows\System32\msvcp_win.dll > 0x00007fff61160000 - 0x00007fff61190000 C:\Windows\System32\IMM32.DLL > 0x00007fff5b580000 - 0x00007fff5b58c000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\vcruntime140_1.dll > 0x00007fff44fa0000 - 0x00007fff4502d000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\msvcp140.dll > 0x00007ffefad70000 - 0x00007ffefb920000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server\jvm.dll > 0x00007fff61ef0000 - 0x00007fff61f9c000 C:\Windows\System32\ADVAPI32.dll > 0x00007fff61cf0000 - 0x00007fff61d8b000 C:\Windows\System32\sechost.dll > 0x00007fff62b60000 - 0x00007fff62c8a000 C:\Windows\System32\RPCRT4.dll > 0x00007fff61ee0000 - 0x00007fff61ee8000 C:\Windows\System32\PSAPI.DLL > 0x00007fff2dc20000 - 0x00007fff2dc29000 C:\Windows\SYSTEM32\WSOCK32.dll > 0x00007fff54b80000 - 0x00007fff54b8a000 C:\Windows\SYSTEM32\VERSION.dll > 0x00007fff518e0000 - 0x00007fff51907000 C:\Windows\SYSTEM32\WINMM.dll > 0x00007fff61bd0000 - 0x00007fff61c3b000 C:\Windows\System32\WS2_32.dll > 0x00007fff5f060000 - 0x00007fff5f072000 C:\Windows\SYSTEM32\kernel.appcore.dll > 0x00007fff5b500000 - 0x00007fff5b50a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jimage.dll > 0x00007fff5e430000 - 0x00007fff5e614000 C:\Windows\SYSTEM32\DBGHELP.DLL > 0x00007fff45170000 - 0x00007fff4519c000 C:\Windows\SYSTEM32\dbgcore.DLL > 0x00007fff60d40000 - 0x00007fff60dc3000 C:\Windows\System32\bcryptPrimitives.dll > 0x00007fff44f70000 - 0x00007fff44f95000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\java.dll > 0x00007fff612c0000 - 0x00007fff619ff000 C:\Windows\System32\SHELL32.dll > 0x00007fff5e620000 - 0x00007fff5edb0000 C:\Windows\SYSTEM32\windows.storage.dll > 0x00007fff62650000 - 0x00007fff629a5000 C:\Windows\System32\combase.dll > 0x00007fff60280000 - 0x00007fff602ae000 C:\Windows\SYSTEM32\Wldp.dll > 0x00007fff61c40000 - 0x00007fff61ced000 C:\Windows\System32\SHCORE.dll > 0x00007fff62f70000 - 0x00007fff62fc5000 C:\Windows\System32\shlwapi.dll > 0x00007fff60770000 - 0x00007fff6078f000 C:\Windows\SYSTEM32\profapi.dll > 0x00007fff44f10000 - 0x00007fff44f29000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\net.dll > 0x00007fff5ada0000 - 0x00007fff5aeac000 C:\Windows\SYSTEM32\WINHTTP.dll > 0x00007fff5ffe0000 - 0x00007fff6004a000 C:\Windows\system32\mswsock.dll > 0x00007fff28650000 - 0x00007fff28665000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\nio.dll > 0x00007ffeda3b0000 - 0x00007ffede7d1000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\libclang.dll > 0x00007fff62ea0000 - 0x00007fff62f6d000 C:\Windows\System32\OLEAUT32.dll > 0x00007fff61190000 - 0x00007fff612ba000 C:\Windows\System32\ole32.dll > 0x00007fff5dac0000 - 0x00007fff5db5e000 C:\Windows\system32\uxtheme.dll > 0x00007fff61e30000 - 0x00007fff61ed9000 C:\Windows\System32\clbcatq.dll > 0x00007fff601d0000 - 0x00007fff601e8000 C:\Windows\SYSTEM32\CRYPTSP.dll > 0x00007fff5f8c0000 - 0x00007fff5f8f4000 C:\Windows\system32\rsaenh.dll > 0x00007fff60930000 - 0x00007fff60957000 C:\Windows\System32\bcrypt.dll > 0x00007fff60730000 - 0x00007fff6075e000 C:\Windows\SYSTEM32\USERENV.dll > 0x00007fff601f0000 - 0x00007fff601fc000 C:\Windows\SYSTEM32\CRYPTBASE.dll > 0x00007fff5fc80000 - 0x00007fff5fcbb000 C:\Windows\SYSTEM32\IPHLPAPI.DLL > 0x00007fff62550000 - 0x00007fff62558000 C:\Windows\System32\NSI.dll > 0x00007fff55080000 - 0x00007fff55097000 C:\Windows\SYSTEM32\dhcpcsvc6.DLL > 0x00007fff55060000 - 0x00007fff5507d000 C:\Windows\SYSTEM32\dhcpcsvc.DLL > 0x00007fff5fcd0000 - 0x00007fff5fd9b000 C:\Windows\SYSTEM32\DNSAPI.dll > > dbghelp: loaded successfully - version: 4.0.5 - missing functions: none > symbol engine: initialized successfully - sym options: 0x614 - pdb path: .;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin;C:\Windows\SYSTEM32;C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server > > VM Arguments: > jvm_args: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract > java_command: jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h > java_class_path (initial): > Launcher Type: SUN_STANDARD > > [Global flags] > intx CICompilerCount = 4 {product} {ergonomic} > uint ConcGCThreads = 2 {product} {ergonomic} > uint G1ConcRefinementThreads = 8 {product} {ergonomic} > size_t G1HeapRegionSize = 2097152 {product} {ergonomic} > uintx GCDrainStackTargetSize = 64 {product} {ergonomic} > size_t InitialHeapSize = 8388608 {product} {command line} > size_t MarkStackSize = 4194304 {product} {ergonomic} > size_t MaxHeapSize = 4223664128 {product} {ergonomic} > size_t MaxNewSize = 2533359616 {product} {ergonomic} > size_t MinHeapDeltaBytes = 2097152 {product} {ergonomic} > size_t MinHeapSize = 8388608 {product} {command line} > uintx NonNMethodCodeHeapSize = 5839372 {pd product} {ergonomic} > uintx NonProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} > uintx ProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} > uintx ReservedCodeCacheSize = 251658240 {pd product} {ergonomic} > bool SegmentedCodeCache = true {product} {ergonomic} > size_t SoftMaxHeapSize = 4223664128 {manageable} {ergonomic} > bool UseCompressedClassPointers = true {product lp64_product} {ergonomic} > bool UseCompressedOops = true {product lp64_product} {ergonomic} > bool UseG1GC = true {product} {ergonomic} > bool UseLargePagesIndividualAllocation = false {pd product} {ergonomic} > > Logging: > Log output configuration: > #0: stdout all=warning uptime,level,tags > #1: stderr all=off uptime,level,tags > > Environment Variables: > JAVA_HOME=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 > PATH=C:\Program Files\Zulu\zulu-11\bin\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Program Files (x86)\apache-ant-1.9.16\bin;C:\Program Files\CMake\bin;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\7-Zip;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\gawk-3.1.6-1-bin\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin;C:\Users\Martin\AppData\Local\Microsoft\WindowsApps;C:\Users\Martin\AppData\Local\atom\bin;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Users\Martin\.dotnet\tools > USERNAME=Martin > OS=Windows_NT > PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 140 Stepping 1, GenuineIntel > > > > --------------- S Y S T E M --------------- > > OS: > Windows 10 , 64 bit Build 19041 (10.0.19041.1348) > OS uptime: 0 days 4:15 hours > Hyper-V role detected > > CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 6 model 140 stepping 1 microcode 0x86, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, avx512f, avx512dq, avx512cd, avx512bw, avx512vl, sha, fma, vzeroupper, avx512_vpopcntdq, avx512_vpclmulqdq, avx512_vaes, avx512_vnni, clflush, clflushopt, clwb, avx512_vbmi2, avx512_vbmi, hv > > Memory: 4k page, system-wide physical 16107M (6064M free) > TotalPageFile size 20971M (AvailPageFile size 8500M) > current process WorkingSet (physical memory assigned to process): 136M, peak: 147M > current process commit charge ("private bytes"): 177M, peak: 191M > > vm_info: OpenJDK 64-Bit Server VM (17-panama+3-167) for windows-amd64 JRE (17-panama+3-167), built on May 18 2021 13:10:19 by "mach5one" with MS VC++ 16.8 (VS2019) > > END. > > > > > Sent with ProtonMail Secure Email. > > ??????? Original Message ??????? > > Le vendredi 12 novembre 2021 ? 15:47, Martin Pernollet a ?crit : > >> Thanks Jon, >> >> MinGW did not create a GL.dll file but rather libfreeglut.dll so I changed to >> >> public class glut_h extends glut_h_3 { >> >> static { >> >> System.loadLibrary("libfreeglut"); >> >> But it still fails, this time due to unresolved dependencies. Dependency Walker reveals tons of unreachable DLL (see screenshot). >> >> This failed attempt is documented here https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/issues/11__;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI_ssFZQS$ >> >> I'll follow your suggestion and update documentation and notify you once I got it working. >> >> ??????? Original Message ??????? >> >> Le vendredi 12 novembre 2021 ? 15:17, Jorn Vernee jorn.vernee at oracle.com a ?crit : >> >>> Hi Martin, >>> >>> Thanks for testing this! >>> >>> The UnsatisfiedLinkError is not from code looking for a header file, >>> >>> it's from looking for a library/.dll file named GL.dll. On Windows >>> >>> though, freeglut needs the opengl libraries that come bundled with >>> >>> Windows (found in C:\Windows\System32), named opengl32 and glu32. The >>> >>> script should already add -l flags for those. >>> >>> WRT the jextract error you see. >>> >>> I have not tried to run the sample with freeglut installed through MingW >>> >>> yet. I instead used the freeglut package for MSVC here: >>> >>> https://urldefense.com/v3/__https://www.transmissionzero.co.uk/software/freeglut-devel/__;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI2nUkNV_$ extracted >>> >>> that in some folder, and the pointed freeglutPath at that folder. >>> >>> Note that jextract is using clang underneath to do the parsing. I know >>> >>> clang works pretty well with MSVC/Windows SDK header files, but I'm >>> >>> guessing it can not understand the MingW headers, looking at your error. >>> >>> I think it's having problems with __MINGW_NOTHROW and >>> >>> __MINGW_ATTRIB_NORETURN, which look like compiler builtins. >>> >>> I'd suggest trying the freeglut package I linked to instead, together >>> >>> with the Windows SDK headers (which clang should find automatically), >>> >>> and taking MingW headers out of the equation for now. We should probably >>> >>> create a README for that sample to include instructions on how to get >>> >>> freeglut. >>> >>> Note that on top of that, you will also have to change Teapot.java to >>> >>> account for a change in parameter names resulting in slightly different >>> >>> code being generated by jextract [1]. >>> >>> HTH, >>> >>> Jorn >>> >>> [1] : >>> >>> diff --git a/opengl/Teapot.java b/opengl/Teapot.java >>> >>> index 22d1f44..d5eb786 100644 >>> >>> --- a/opengl/Teapot.java >>> >>> +++ b/opengl/Teapot.java >>> >>> @@ -79,8 +79,8 @@ public class Teapot { >>> >>> glutInitWindowSize(500, 500); >>> >>> glutCreateWindow(allocator.allocateUtf8String("Hello Panama!")); >>> >>> var teapot = new Teapot(allocator); >>> >>> -??????????? var displayStub = >>> >>> glutDisplayFunc$func.allocate(teapot::display, scope); >>> >>> -??????????? var idleStub = glutIdleFunc$func.allocate(teapot::onIdle, >>> >>> scope); >>> >>> +??????????? var displayStub = >>> >>> glutDisplayFunc$callback.allocate(teapot::display, scope); >>> >>> +??????????? var idleStub = >>> >>> glutIdleFunc$callback.allocate(teapot::onIdle, scope); >>> >>> glutDisplayFunc(displayStub); >>> >>> glutIdleFunc(idleStub); >>> >>> glutMainLoop(); >>> >>> On 12/11/2021 13:01, Martin Pernollet wrote: >>> >>>> Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows : >>>> >>>> public class glut_h extends glut_h_3 { >>>> >>>> static { >>>> >>>> System.loadLibrary("GL"); >>>> >>>> System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT"); >>>> >>>> } >>>> >>>> while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW. >>>> >>>> Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir. >>>> >>>> So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception : >>>> >>>> PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1 >>>> >>>> [...] >>>> >>>> freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32 >>>> >>>> WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract >>>> >>>> C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator >>>> >>>> ERROR: jextract exited with non-zero exit code: 3 >>>> >>>> Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 : >>>> >>>> 358: #ifndef _CRT_TERMINATE_DEFINED >>>> >>>> 359: #define _CRT_TERMINATE_DEFINED >>>> >>>> 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; >>>> >>>> 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN; >>>> >>>> I should mention that >>>> >>>> - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct. >>>> - I verified GCC and G++ are callable from Powershell >>>> - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself. >>>> >>>> Is this stdlib error something some of you already faced? How did you fix? >>>> >>>> Thanks! >>>> >>>> Sent with ProtonMail Secure Email. >>>> >>>> ??????? Original Message ??????? >>>> >>>> Le lundi 18 octobre 2021 ? 11:29, Rado Smogura mail at smogura.eu a ?crit : >>>> >>>>> Hi Martin, >>>>> >>>>> Let me answer the last questions about JExtract and .h files for every >>>>> >>>>> platform. >>>>> >>>>> It may be needed to do separate bindings, unless you can prove >>>>> >>>>> otherwise. The specifications provides .h files and names, but may not >>>>> >>>>> be clear if, >>>>> >>>>> - given name is variable, or define >>>>> >>>>> - values set to const / variable >>>>> >>>>> - expr() is method or define >>>>> >>>>> There was one experiment with POSIX, where even so standard things like >>>>> >>>>> net may differ on values assigned to DEFINED between Linux & OSX. >>>>> >>>>> Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other, >>>>> >>>>> and this values will be "inlined" into extracted code. >>>>> >>>>> However how exactly is with OpenGL I don't know. >>>>> >>>>> Kind regards, >>>>> >>>>> Rado >>>>> >>>>> On 17.10.2021 15:20, Martin Pernollet wrote: >>>>> >>>>> >>>>>> Report about more intensive use of foreign function API >>>>>> >>>>>> I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn?t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow : >>>>>> >>>>>> void onIdle() { >>>>>> >>>>>> throw new IllegalArgumentException("Teapot does not support coffee"); >>>>>> >>>>>> } >>>>>> >>>>>> My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412. >>>>>> >>>>>> I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before. >>>>>> >>>>>> Integration in an AWT Canvas >>>>>> >>>>>> Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU. >>>>>> >>>>>> It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc. >>>>>> >>>>>> I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL. >>>>>> >>>>>> Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) >>>>>> >>>>>> I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way). >>>>>> >>>>>> More practical questions about JExtract >>>>>> >>>>>> I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case. >>>>>> >>>>>> Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM? >>>>>> >>>>>> Thanks for reading! >>>>>> >>>>>> Martin >>>>>> >>>>>> [0] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8bHkQ00p$ >>>>>> >>>>>> [1] https://urldefense.com/v3/https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8ROseeEa$ >>>>>> >>>>>> [2] https://urldefense.com/v3/https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8WkFrawU$ From martin.pernollet at protonmail.com Fri Nov 12 15:50:57 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Fri, 12 Nov 2021 15:50:57 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: =?us-ascii?Q?_<8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com>__<3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a=5Frexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=3D@protonmail.com>______?= Message-ID: Yes, I used Build 17-panama+3-167 (2021/5/18) and the fix you mention was merged later. Do you have an idea of when the next Panama EA build will be made available online? Building JDK myself looks like an interesting experience but I fear it will take me lot of time. Martin Sent with ProtonMail Secure Email. ??????? Original Message ??????? Le vendredi 12 novembre 2021 ? 16:25, Jorn Vernee a ?crit : > Hi Martin, > > This looks like a case of: https://github.com/openjdk/jdk17/pull/35 > > Are you using the panama snapshot from jdk.java.net? That snapshot > > doesn't contain the fix AFAIK. The samples are also made for the latest > > panama-foreign API, so they won't work with the snapshot (at least not > > out of the box). > > I think the only solution to the crash is to build the > > panama-foreign/foreign-jextract branch yourself. > > Sorry, > > Jorn > > On 12/11/2021 16:09, Martin Pernollet wrote: > > > When I now try with the precompiled freeglut you suggest I got a jextract crash. My exact command was > > > > C:\Program" "Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe `-I "C:\\Users\\Martin\\Dev\\jzy3d\\external\\freeglut\\include"` > > > > "-l" opengl32 `"-l" glu32` > > > > "-l" freeglut `"-t" "opengl"` > > > > "--" ` > > > > "C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h" > > > > And the core dump file says > > > > A fatal error has been detected by the Java Runtime Environment: > > ================================================================ > > > > Internal Error (codeBuffer.cpp:972), pid=8664, tid=17112 > > ======================================================== > > > > guarantee(sect->end() <= tend) failed: sanity > > ============================================= > > > > JRE version: OpenJDK Runtime Environment (17.0+3) (build 17-panama+3-167) > > ========================================================================= > > > > Java VM: OpenJDK 64-Bit Server VM (17-panama+3-167, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) > > ============================================================================================================================================== > > > > No core dump will be written. Minidumps are not enabled by default on client versions of Windows > > ================================================================================================ > > > > If you would like to submit a bug report, please visit: > > ======================================================= > > > > https://urldefense.com/v3/https://bugreport.java.com/bugreport/crash.jsp;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI5KK9Rju$ > > ============================================================================================================================================================ > > > > --------------- S U M M A R Y ------------ > > > > Command Line: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h > > > > Host: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 8 cores, 15G, Windows 10 , 64 bit Build 19041 (10.0.19041.1348) > > > > Time: Fri Nov 12 16:06:50 2021 Europe de l , 64 bit Build 19041 (10.0.19041.1348) elapsed time: 0.603555 seconds (0d 0h 0m 0s) > > > > --------------- T H R E A D --------------- > > > > Current thread (0x000001beaa55be10): JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] > > > > Stack: [0x0000003933800000,0x0000003933900000] > > > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > > > > V [jvm.dll+0x668f4a] > > > > V [jvm.dll+0x7c69a9] > > > > V [jvm.dll+0x7c814e] > > > > V [jvm.dll+0x7c8757] > > > > V [jvm.dll+0x23ec9c] > > > > V [jvm.dll+0x1f92d0] > > > > V [jvm.dll+0x795431] > > > > V [jvm.dll+0x792fa9] > > > > C 0x000001beb1dfd661 > > > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > > > > j jdk.internal.foreign.abi.ProgrammableUpcallHandler.allocateOptimizedUpcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/ABIDescriptor;Ljdk/internal/foreign/abi/ProgrammableUpcallHandler$CallRegs;)J+0 jdk.incubator.foreign at 17-panama > > > > j jdk.internal.foreign.abi.ProgrammableUpcallHandler.make(Ljdk/internal/foreign/abi/ABIDescriptor;Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/CallingSequence;)Ljdk/internal/foreign/abi/UpcallHandler;+380 jdk.incubator.foreign at 17-panama > > > > j jdk.internal.foreign.abi.x64.windows.CallArranger.arrangeUpcall(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;Ljdk/incubator/foreign/FunctionDescriptor;)Ljdk/internal/foreign/abi/UpcallHandler;+28 jdk.incubator.foreign at 17-panama > > > > j jdk.internal.foreign.abi.x64.windows.Windowsx64Linker.upcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/incubator/foreign/FunctionDescriptor;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+35 jdk.incubator.foreign at 17-panama > > > > j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+34 jdk.incubator.jextract at 17-panama > > > > j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;)Ljdk/incubator/foreign/MemoryAddress;+7 jdk.incubator.jextract at 17-panama > > > > j jdk.internal.clang.libclang.CXCursorVisitor.allocate(Ljdk/internal/clang/libclang/CXCursorVisitor;)Ljdk/incubator/foreign/MemoryAddress;+8 jdk.incubator.jextract at 17-panama > > > > j jdk.internal.clang.Cursor$CursorChildren.()V+15 jdk.incubator.jextract at 17-panama > > > > v ~StubRoutines::call_stub > > > > j jdk.internal.clang.Cursor.children()Ljava/util/stream/Stream;+1 jdk.incubator.jextract at 17-panama > > > > j jdk.internal.jextract.impl.Parser.parse(Ljava/nio/file/Path;Ljava/util/Collection;)Ljdk/incubator/jextract/Declaration$Scoped;+66 jdk.incubator.jextract at 17-panama > > > > j jdk.incubator.jextract.JextractTool.parse(Ljava/util/List;[Ljava/lang/String;)Ljdk/incubator/jextract/Declaration$Scoped;+55 jdk.incubator.jextract at 17-panama > > > > j jdk.incubator.jextract.JextractTool.run([Ljava/lang/String;)I+904 jdk.incubator.jextract at 17-panama > > > > j jdk.incubator.jextract.JextractTool.main([Ljava/lang/String;)V+46 jdk.incubator.jextract at 17-panama > > > > v ~StubRoutines::call_stub > > > > --------------- P R O C E S S --------------- > > > > Threads class SMR info: > > > > _java_thread_list=0x000001bece7196e0, length=13, elements={ > > > > 0x000001beaa55be10, 0x000001becd023240, 0x000001becd023e00, 0x000001becd0394b0, > > > > 0x000001becd03a070, 0x000001becd03ea50, 0x000001becd03f410, 0x000001becd0401b0, > > > > 0x000001becd041400, 0x000001becd042e10, 0x000001becdc945a0, 0x000001becdcab950, > > > > 0x000001becdf7e080 > > > > } > > > > Java Threads: ( => current thread ) > > > > =>0x000001beaa55be10 JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] > > > > 0x000001becd023240 JavaThread "Reference Handler" daemon [_thread_blocked, id=16356, stack(0x0000003933f00000,0x0000003934000000)] > > > > 0x000001becd023e00 JavaThread "Finalizer" daemon [_thread_blocked, id=6204, stack(0x0000003934000000,0x0000003934100000)] > > > > 0x000001becd0394b0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=972, stack(0x0000003934100000,0x0000003934200000)] > > > > 0x000001becd03a070 JavaThread "Attach Listener" daemon [_thread_blocked, id=2084, stack(0x0000003934200000,0x0000003934300000)] > > > > 0x000001becd03ea50 JavaThread "Service Thread" daemon [_thread_blocked, id=18128, stack(0x0000003934300000,0x0000003934400000)] > > > > 0x000001becd03f410 JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=3404, stack(0x0000003934400000,0x0000003934500000)] > > > > 0x000001becd0401b0 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=10160, stack(0x0000003934500000,0x0000003934600000)] > > > > 0x000001becd041400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=15728, stack(0x0000003934600000,0x0000003934700000)] > > > > 0x000001becd042e10 JavaThread "Sweeper thread" daemon [_thread_blocked, id=3932, stack(0x0000003934700000,0x0000003934800000)] > > > > 0x000001becdc945a0 JavaThread "Notification Thread" daemon [_thread_blocked, id=12368, stack(0x0000003934800000,0x0000003934900000)] > > > > 0x000001becdcab950 JavaThread "Common-Cleaner" daemon [_thread_blocked, id=15996, stack(0x0000003934a00000,0x0000003934b00000)] > > > > 0x000001becdf7e080 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=8236, stack(0x0000003934e00000,0x0000003934f00000)] > > > > Other Threads: > > > > 0x000001becd01c730 VMThread "VM Thread" [stack: 0x0000003933e00000,0x0000003933f00000] [id=8136] > > > > 0x000001becd00d9b0 WatcherThread [stack: 0x0000003934900000,0x0000003934a00000] [id=11228] > > > > 0x000001beaa5a9a40 GCTaskThread "GC Thread#0" [stack: 0x0000003933900000,0x0000003933a00000] [id=15472] > > > > 0x000001becde6f060 GCTaskThread "GC Thread#1" [stack: 0x0000003934b00000,0x0000003934c00000] [id=9408] > > > > 0x000001becde782a0 GCTaskThread "GC Thread#2" [stack: 0x0000003934c00000,0x0000003934d00000] [id=15952] > > > > 0x000001becde78560 GCTaskThread "GC Thread#3" [stack: 0x0000003934d00000,0x0000003934e00000] [id=17212] > > > > 0x000001bece9140e0 GCTaskThread "GC Thread#4" [stack: 0x0000003934f00000,0x0000003935000000] [id=13940] > > > > 0x000001bece914ea0 GCTaskThread "GC Thread#5" [stack: 0x0000003935000000,0x0000003935100000] [id=12744] > > > > 0x000001beaa5ba550 ConcurrentGCThread "G1 Main Marker" [stack: 0x0000003933a00000,0x0000003933b00000] [id=9236] > > > > 0x000001beaa5bbf70 ConcurrentGCThread "G1 Conc#0" [stack: 0x0000003933b00000,0x0000003933c00000] [id=17776] > > > > 0x000001beaa5e6a80 ConcurrentGCThread "G1 Refine#0" [stack: 0x0000003933c00000,0x0000003933d00000] [id=1088] > > > > 0x000001beaa5e84c0 ConcurrentGCThread "G1 Service" [stack: 0x0000003933d00000,0x0000003933e00000] [id=3248] > > > > Threads with active compile tasks: > > > > C2 CompilerThread0 608 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) > > > > VM state: not at safepoint (normal execution) > > > > VM Mutex/Monitor currently owned by a thread: None > > > > Heap address: 0x0000000704400000, size: 4028 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 > > > > CDS archive(s) mapped at: [0x0000000800000000-0x0000000800bb0000-0x0000000800bb0000), size 12255232, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. > > > > Compressed class space mapped at: 0x0000000800c00000-0x0000000840c00000, reserved size: 1073741824 > > > > Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 > > > > GC Precious Log: > > > > CPUs: 8 total, 8 available > > > > Memory: 16107M > > > > Large Page Support: Disabled > > > > NUMA Support: Disabled > > > > Compressed Oops: Enabled (Zero based) > > > > Heap Region Size: 2M > > > > Heap Min Capacity: 8M > > > > Heap Initial Capacity: 8M > > > > Heap Max Capacity: 4028M > > > > Pre-touch: Disabled > > > > Parallel Workers: 8 > > > > Concurrent Workers: 2 > > > > Concurrent Refinement Workers: 8 > > > > Periodic GC: Disabled > > > > Heap: > > > > garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > > > Metaspace used 4346K, committed 5056K, reserved 1056768K > > > > class space used 589K, committed 896K, reserved 1048576K > > > > Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts), HC=humongous(continues), CS=collection set, F=free, OA=open archive, CA=closed archive, TAMS=top-at-mark-start (previous, next) > > > > | 0|0x0000000704400000, 0x00000007044e4e00, 0x0000000704600000| 44%| O| |TAMS 0x0000000704400000, 0x0000000704400000| Untracked > > > > | 1|0x0000000704600000, 0x0000000704600000, 0x0000000704800000| 0%| F| |TAMS 0x0000000704600000, 0x0000000704600000| Untracked > > > > | 2|0x0000000704800000, 0x00000007048fb810, 0x0000000704a00000| 49%| S|CS|TAMS 0x0000000704800000, 0x0000000704800000| Complete > > > > | 3|0x0000000704a00000, 0x0000000704bfa230, 0x0000000704c00000| 98%| E| |TAMS 0x0000000704a00000, 0x0000000704a00000| Complete > > > > Card table byte_map: [0x000001bec1900000,0x000001bec20e0000] _byte_map_base: 0x000001bebe0de000 > > > > Marking Bits (Prev, Next): (CMBitMap*) 0x000001beaa5aa060, (CMBitMap*) 0x000001beaa5aa0a0 > > > > Prev Bits: [0x000001bec28c0000, 0x000001bec67b0000) > > > > Next Bits: [0x000001bec67b0000, 0x000001beca6a0000) > > > > Polling page: 0x000001bea8380000 > > > > Metaspace: > > > > Usage: > > > > Non-class: 3.67 MB used. > > > > Class: 589.17 KB used. > > > > Both: 4.24 MB used. > > > > Virtual space: > > > > Non-class space: 8.00 MB reserved, 4.06 MB ( 51%) committed, 1 nodes. > > > > Class space: 1.00 GB reserved, 896.00 KB ( <1%) committed, 1 nodes. > > > > Both: 1.01 GB reserved, 4.94 MB ( <1%) committed. > > > > Chunk freelists: > > > > Non-Class: 2.55 MB > > > > Class: 2.96 MB > > > > Both: 5.51 MB > > > > MaxMetaspaceSize: unlimited > > > > CompressedClassSpaceSize: 1.00 GB > > > > Initial GC threshold: 21.00 MB > > > > Current GC threshold: 21.00 MB > > > > CDS: on > > > > MetaspaceReclaimPolicy: balanced > > > > - commit_granule_bytes: 65536. > > - commit_granule_words: 8192. > > - virtual_space_node_default_size: 1048576. > > - enlarge_chunks_in_place: 1. > > - new_chunks_are_fully_committed: 0. > > - uncommit_free_chunks: 1. > > - use_allocation_guard: 0. > > - handle_deallocations: 1. > > > > Internal statistics: > > > > num_allocs_failed_limit: 0. > > > > num_arena_births: 990. > > > > num_arena_deaths: 0. > > > > num_vsnodes_births: 2. > > > > num_vsnodes_deaths: 0. > > > > num_space_committed: 79. > > > > num_space_uncommitted: 0. > > > > num_chunks_returned_to_freelist: 0. > > > > num_chunks_taken_from_freelist: 1166. > > > > num_chunk_merges: 0. > > > > num_chunk_splits: 758. > > > > num_chunks_enlarged: 370. > > > > num_purges: 0. > > > > CodeHeap 'non-profiled nmethods': size=120000Kb used=542Kb max_used=542Kb free=119458Kb > > > > bounds [0x000001beb98c0000, 0x000001beb9b30000, 0x000001bec0df0000] > > > > CodeHeap 'profiled nmethods': size=120000Kb used=1537Kb max_used=1537Kb free=118462Kb > > > > bounds [0x000001beb2390000, 0x000001beb2600000, 0x000001beb98c0000] > > > > CodeHeap 'non-nmethods': size=5760Kb used=1214Kb max_used=1246Kb free=4545Kb > > > > bounds [0x000001beb1df0000, 0x000001beb2060000, 0x000001beb2390000] > > > > total_blobs=1537 nmethods=1035 adapters=412 > > > > compilation: enabled > > > > stopped_count=0, restarted_count=0 > > > > full_count=0 > > > > Compilation events (20 events): > > > > Event: 0.590 Thread 0x000001becd041400 1020 3 java.lang.invoke.DirectMethodHandle:: (148 bytes) > > > > Event: 0.591 Thread 0x000001becd0401b0 nmethod 1019 0x000001beb9945710 code [0x000001beb9945880, 0x000001beb9945958] > > > > Event: 0.591 Thread 0x000001becd041400 nmethod 1020 0x000001beb2508510 code [0x000001beb25087c0, 0x000001beb2509748] > > > > Event: 0.591 Thread 0x000001becd0401b0 1021 4 jdk.internal.org.objectweb.asm.Frame::getLocal (46 bytes) > > > > Event: 0.591 Thread 0x000001becd0401b0 nmethod 1021 0x000001beb9946010 code [0x000001beb9946180, 0x000001beb9946258] > > > > Event: 0.592 Thread 0x000001becd041400 1024 3 java.lang.invoke.LambdaFormEditor$TransformKey::of (51 bytes) > > > > Event: 0.593 Thread 0x000001becd041400 nmethod 1024 0x000001beb2509c90 code [0x000001beb2509e80, 0x000001beb250a448] > > > > Event: 0.593 Thread 0x000001becd041400 1025 3 java.lang.invoke.LambdaFormEditor$TransformKey::packedBytes (39 bytes) > > > > Event: 0.593 Thread 0x000001becd041400 nmethod 1025 0x000001beb250a610 code [0x000001beb250a7a0, 0x000001beb250a8b8] > > > > Event: 0.593 Thread 0x000001becdf7e080 1028 4 java.lang.invoke.LambdaForm$BasicType::basicType (19 bytes) > > > > Event: 0.593 Thread 0x000001becd0401b0 1029 4 jdk.internal.org.objectweb.asm.Frame::pop (42 bytes) > > > > Event: 0.593 Thread 0x000001becd041400 1031 3 java.lang.invoke.MethodHandles::collectArguments (47 bytes) > > > > Event: 0.593 Thread 0x000001becd0401b0 nmethod 1029 0x000001beb9946910 code [0x000001beb9946a80, 0x000001beb9946b58] > > > > Event: 0.593 Thread 0x000001becd0401b0 1030 4 jdk.internal.org.objectweb.asm.Frame::merge (317 bytes) > > > > Event: 0.593 Thread 0x000001becd041400 nmethod 1031 0x000001beb250a990 code [0x000001beb250abc0, 0x000001beb250b3e8] > > > > Event: 0.593 Thread 0x000001becd041400 1032 3 java.lang.invoke.MethodHandles::collectArgumentsChecks (124 bytes) > > > > Event: 0.594 Thread 0x000001becd0401b0 nmethod 1030 0x000001beb9946c10 code [0x000001beb9946d80, 0x000001beb9946e78] > > > > Event: 0.594 Thread 0x000001becd0401b0 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) > > > > Event: 0.594 Thread 0x000001becd041400 nmethod 1032 0x000001beb250b790 code [0x000001beb250bb00, 0x000001beb250d2b8] > > > > Event: 0.594 Thread 0x000001becd041400 1033 3 java.lang.invoke.LambdaFormEditor::collectArgumentsForm (169 bytes) > > > > GC Heap History (10 events): > > > > Event: 0.086 GC heap before > > > > {Heap before GC invocations=0 (full 0): > > > > garbage-first heap total 8192K, used 2048K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 0 survivors (0K) > > > > Metaspace used 1471K, committed 1664K, reserved 1056768K > > > > class space used 151K, committed 256K, reserved 1048576K > > > > } > > > > Event: 0.088 GC heap after > > > > {Heap after GC invocations=1 (full 0): > > > > garbage-first heap total 8192K, used 1168K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > > > Metaspace used 1471K, committed 1664K, reserved 1056768K > > > > class space used 151K, committed 256K, reserved 1048576K > > > > } > > > > Event: 0.135 GC heap before > > > > {Heap before GC invocations=1 (full 0): > > > > garbage-first heap total 8192K, used 3216K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > > > Metaspace used 2586K, committed 2880K, reserved 1056768K > > > > class space used 297K, committed 448K, reserved 1048576K > > > > } > > > > Event: 0.137 GC heap after > > > > {Heap after GC invocations=2 (full 0): > > > > garbage-first heap total 8192K, used 1270K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > > > Metaspace used 2586K, committed 2880K, reserved 1056768K > > > > class space used 297K, committed 448K, reserved 1048576K > > > > } > > > > Event: 0.165 GC heap before > > > > {Heap before GC invocations=2 (full 0): > > > > garbage-first heap total 8192K, used 3318K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > > > Metaspace used 2912K, committed 3328K, reserved 1056768K > > > > class space used 360K, committed 576K, reserved 1048576K > > > > } > > > > Event: 0.167 GC heap after > > > > {Heap after GC invocations=3 (full 0): > > > > garbage-first heap total 8192K, used 1460K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > > > Metaspace used 2912K, committed 3328K, reserved 1056768K > > > > class space used 360K, committed 576K, reserved 1048576K > > > > } > > > > Event: 0.366 GC heap before > > > > {Heap before GC invocations=3 (full 0): > > > > garbage-first heap total 8192K, used 3508K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > > > Metaspace used 3240K, committed 3712K, reserved 1056768K > > > > class space used 418K, committed 640K, reserved 1048576K > > > > } > > > > Event: 0.368 GC heap after > > > > {Heap after GC invocations=4 (full 0): > > > > garbage-first heap total 8192K, used 1629K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > > > Metaspace used 3240K, committed 3712K, reserved 1056768K > > > > class space used 418K, committed 640K, reserved 1048576K > > > > } > > > > Event: 0.570 GC heap before > > > > {Heap before GC invocations=4 (full 0): > > > > garbage-first heap total 8192K, used 3677K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > > > Metaspace used 4023K, committed 4608K, reserved 1056768K > > > > class space used 525K, committed 832K, reserved 1048576K > > > > } > > > > Event: 0.572 GC heap after > > > > {Heap after GC invocations=5 (full 0): > > > > garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > > > Metaspace used 4023K, committed 4608K, reserved 1056768K > > > > class space used 525K, committed 832K, reserved 1048576K > > > > } > > > > Deoptimization events (14 events): > > > > Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb98c3cac relative=0x000000000000020c > > > > Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb98c3cac method=java.lang.String.hashCode()I @ 42 c2 > > > > Event: 0.034 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb98c3cac sp=0x00000039338fe520 > > > > Event: 0.034 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe4b8 mode 2 > > > > Event: 0.122 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb23ab367 sp=0x00000039338fd790 > > > > Event: 0.122 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e46763 sp=0x00000039338fcbb0 mode 0 > > > > Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb990a7e0 relative=0x0000000000007740 > > > > Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb990a7e0 method=jdk.internal.org.objectweb.asm.Frame.execute(IILjdk/internal/org/objectweb/asm/Symbol;Ljdk/internal/org/objectweb/asm/SymbolTable;)V @ 1 c2 > > > > Event: 0.584 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb990a7e0 sp=0x00000039338fcef0 > > > > Event: 0.584 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fcea8 mode 2 > > > > Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffffcc fr.pc=0x000001beb9943df4 relative=0x0000000000000354 > > > > Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: reason=intrinsic_or_type_checked_inlining action=make_not_entrant pc=0x000001beb9943df4 method=java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; @ 35 c2 > > > > Event: 0.592 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb9943df4 sp=0x00000039338fe2b0 > > > > Event: 0.592 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe258 mode 2 > > > > Classes unloaded (0 events): > > > > No events > > > > Classes redefined (0 events): > > > > No events > > > > Internal exceptions (20 events): > > > > Event: 0.424 Thread 0x000001beaa55be10 Exception (0x0000000704b67fa8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.566 Thread 0x000001beaa55be10 Exception (0x0000000704ba0908) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.572 Thread 0x000001beaa55be10 Exception (0x0000000704a048c8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.574 Thread 0x000001beaa55be10 Exception (0x0000000704a359b8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.576 Thread 0x000001beaa55be10 Exception (0x0000000704a69260) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.578 Thread 0x000001beaa55be10 Exception (0x0000000704a85548) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.579 Thread 0x000001beaa55be10 Exception (0x0000000704a9b548) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.581 Thread 0x000001beaa55be10 Exception (0x0000000704ac7840) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.582 Thread 0x000001beaa55be10 Exception (0x0000000704acada8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b0f9a8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b13248) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.588 Thread 0x000001beaa55be10 Exception (0x0000000704b66608) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b69ec0) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b72a48) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b765d8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7a480) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7e200) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b99bd0) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b9d880) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.593 Thread 0x000001beaa55be10 Exception (0x0000000704bd0ae8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Events (20 events): > > > > Event: 0.423 loading class java/io/DeleteOnExitHook done > > > > Event: 0.423 loading class java/io/DeleteOnExitHook$1 > > > > Event: 0.424 loading class java/io/DeleteOnExitHook$1 done > > > > Event: 0.550 Thread 0x000001beceebb670 Thread exited: 0x000001beceebb670 > > > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef > > > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator > > > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator done > > > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef done > > > > Event: 0.551 loading class java/util/stream/Streams$2 > > > > Event: 0.551 loading class java/util/stream/Streams$2 done > > > > Event: 0.570 Executing VM operation: G1CollectForAllocation > > > > Event: 0.572 Executing VM operation: G1CollectForAllocation done > > > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator > > > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator > > > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator done > > > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator done > > > > Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler > > > > Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler done > > > > Event: 0.594 loading class java/lang/invoke/MethodHandle$1 > > > > Event: 0.594 loading class java/lang/invoke/MethodHandle$1 done > > > > Dynamic libraries: > > > > 0x00007ff670d20000 - 0x00007ff670d28000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe > > > > 0x00007fff63110000 - 0x00007fff63305000 C:\Windows\SYSTEM32\ntdll.dll > > > > 0x00007fff61a00000 - 0x00007fff61abe000 C:\Windows\System32\KERNEL32.DLL > > > > 0x00007fff60960000 - 0x00007fff60c28000 C:\Windows\System32\KERNELBASE.dll > > > > 0x00007fff60830000 - 0x00007fff60930000 C:\Windows\System32\ucrtbase.dll > > > > 0x00007fff567c0000 - 0x00007fff567d8000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jli.dll > > > > 0x00007fff57310000 - 0x00007fff5732a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\VCRUNTIME140.dll > > > > 0x00007fff629b0000 - 0x00007fff62b51000 C:\Windows\System32\USER32.dll > > > > 0x00007fff60f30000 - 0x00007fff60f52000 C:\Windows\System32\win32u.dll > > > > 0x00007fff61ac0000 - 0x00007fff61aeb000 C:\Windows\System32\GDI32.dll > > > > 0x00007fff45910000 - 0x00007fff45baa000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\COMCTL32.dll > > > > 0x00007fff60c30000 - 0x00007fff60d3b000 C:\Windows\System32\gdi32full.dll > > > > 0x00007fff62fd0000 - 0x00007fff6306e000 C:\Windows\System32\msvcrt.dll > > > > 0x00007fff610c0000 - 0x00007fff6115d000 C:\Windows\System32\msvcp_win.dll > > > > 0x00007fff61160000 - 0x00007fff61190000 C:\Windows\System32\IMM32.DLL > > > > 0x00007fff5b580000 - 0x00007fff5b58c000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\vcruntime140_1.dll > > > > 0x00007fff44fa0000 - 0x00007fff4502d000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\msvcp140.dll > > > > 0x00007ffefad70000 - 0x00007ffefb920000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server\jvm.dll > > > > 0x00007fff61ef0000 - 0x00007fff61f9c000 C:\Windows\System32\ADVAPI32.dll > > > > 0x00007fff61cf0000 - 0x00007fff61d8b000 C:\Windows\System32\sechost.dll > > > > 0x00007fff62b60000 - 0x00007fff62c8a000 C:\Windows\System32\RPCRT4.dll > > > > 0x00007fff61ee0000 - 0x00007fff61ee8000 C:\Windows\System32\PSAPI.DLL > > > > 0x00007fff2dc20000 - 0x00007fff2dc29000 C:\Windows\SYSTEM32\WSOCK32.dll > > > > 0x00007fff54b80000 - 0x00007fff54b8a000 C:\Windows\SYSTEM32\VERSION.dll > > > > 0x00007fff518e0000 - 0x00007fff51907000 C:\Windows\SYSTEM32\WINMM.dll > > > > 0x00007fff61bd0000 - 0x00007fff61c3b000 C:\Windows\System32\WS2_32.dll > > > > 0x00007fff5f060000 - 0x00007fff5f072000 C:\Windows\SYSTEM32\kernel.appcore.dll > > > > 0x00007fff5b500000 - 0x00007fff5b50a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jimage.dll > > > > 0x00007fff5e430000 - 0x00007fff5e614000 C:\Windows\SYSTEM32\DBGHELP.DLL > > > > 0x00007fff45170000 - 0x00007fff4519c000 C:\Windows\SYSTEM32\dbgcore.DLL > > > > 0x00007fff60d40000 - 0x00007fff60dc3000 C:\Windows\System32\bcryptPrimitives.dll > > > > 0x00007fff44f70000 - 0x00007fff44f95000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\java.dll > > > > 0x00007fff612c0000 - 0x00007fff619ff000 C:\Windows\System32\SHELL32.dll > > > > 0x00007fff5e620000 - 0x00007fff5edb0000 C:\Windows\SYSTEM32\windows.storage.dll > > > > 0x00007fff62650000 - 0x00007fff629a5000 C:\Windows\System32\combase.dll > > > > 0x00007fff60280000 - 0x00007fff602ae000 C:\Windows\SYSTEM32\Wldp.dll > > > > 0x00007fff61c40000 - 0x00007fff61ced000 C:\Windows\System32\SHCORE.dll > > > > 0x00007fff62f70000 - 0x00007fff62fc5000 C:\Windows\System32\shlwapi.dll > > > > 0x00007fff60770000 - 0x00007fff6078f000 C:\Windows\SYSTEM32\profapi.dll > > > > 0x00007fff44f10000 - 0x00007fff44f29000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\net.dll > > > > 0x00007fff5ada0000 - 0x00007fff5aeac000 C:\Windows\SYSTEM32\WINHTTP.dll > > > > 0x00007fff5ffe0000 - 0x00007fff6004a000 C:\Windows\system32\mswsock.dll > > > > 0x00007fff28650000 - 0x00007fff28665000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\nio.dll > > > > 0x00007ffeda3b0000 - 0x00007ffede7d1000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\libclang.dll > > > > 0x00007fff62ea0000 - 0x00007fff62f6d000 C:\Windows\System32\OLEAUT32.dll > > > > 0x00007fff61190000 - 0x00007fff612ba000 C:\Windows\System32\ole32.dll > > > > 0x00007fff5dac0000 - 0x00007fff5db5e000 C:\Windows\system32\uxtheme.dll > > > > 0x00007fff61e30000 - 0x00007fff61ed9000 C:\Windows\System32\clbcatq.dll > > > > 0x00007fff601d0000 - 0x00007fff601e8000 C:\Windows\SYSTEM32\CRYPTSP.dll > > > > 0x00007fff5f8c0000 - 0x00007fff5f8f4000 C:\Windows\system32\rsaenh.dll > > > > 0x00007fff60930000 - 0x00007fff60957000 C:\Windows\System32\bcrypt.dll > > > > 0x00007fff60730000 - 0x00007fff6075e000 C:\Windows\SYSTEM32\USERENV.dll > > > > 0x00007fff601f0000 - 0x00007fff601fc000 C:\Windows\SYSTEM32\CRYPTBASE.dll > > > > 0x00007fff5fc80000 - 0x00007fff5fcbb000 C:\Windows\SYSTEM32\IPHLPAPI.DLL > > > > 0x00007fff62550000 - 0x00007fff62558000 C:\Windows\System32\NSI.dll > > > > 0x00007fff55080000 - 0x00007fff55097000 C:\Windows\SYSTEM32\dhcpcsvc6.DLL > > > > 0x00007fff55060000 - 0x00007fff5507d000 C:\Windows\SYSTEM32\dhcpcsvc.DLL > > > > 0x00007fff5fcd0000 - 0x00007fff5fd9b000 C:\Windows\SYSTEM32\DNSAPI.dll > > > > dbghelp: loaded successfully - version: 4.0.5 - missing functions: none > > > > symbol engine: initialized successfully - sym options: 0x614 - pdb path: .;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin;C:\Windows\SYSTEM32;C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server > > > > VM Arguments: > > > > jvm_args: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract > > > > java_command: jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h > > > > java_class_path (initial): > > > > Launcher Type: SUN_STANDARD > > > > [Global flags] > > > > intx CICompilerCount = 4 {product} {ergonomic} > > > > uint ConcGCThreads = 2 {product} {ergonomic} > > > > uint G1ConcRefinementThreads = 8 {product} {ergonomic} > > > > size_t G1HeapRegionSize = 2097152 {product} {ergonomic} > > > > uintx GCDrainStackTargetSize = 64 {product} {ergonomic} > > > > size_t InitialHeapSize = 8388608 {product} {command line} > > > > size_t MarkStackSize = 4194304 {product} {ergonomic} > > > > size_t MaxHeapSize = 4223664128 {product} {ergonomic} > > > > size_t MaxNewSize = 2533359616 {product} {ergonomic} > > > > size_t MinHeapDeltaBytes = 2097152 {product} {ergonomic} > > > > size_t MinHeapSize = 8388608 {product} {command line} > > > > uintx NonNMethodCodeHeapSize = 5839372 {pd product} {ergonomic} > > > > uintx NonProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} > > > > uintx ProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} > > > > uintx ReservedCodeCacheSize = 251658240 {pd product} {ergonomic} > > > > bool SegmentedCodeCache = true {product} {ergonomic} > > > > size_t SoftMaxHeapSize = 4223664128 {manageable} {ergonomic} > > > > bool UseCompressedClassPointers = true {product lp64_product} {ergonomic} > > > > bool UseCompressedOops = true {product lp64_product} {ergonomic} > > > > bool UseG1GC = true {product} {ergonomic} > > > > bool UseLargePagesIndividualAllocation = false {pd product} {ergonomic} > > > > Logging: > > > > Log output configuration: > > > > #0: stdout all=warning uptime,level,tags > > > > #1: stderr all=off uptime,level,tags > > > > Environment Variables: > > > > JAVA_HOME=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 > > > > PATH=C:\Program Files\Zulu\zulu-11\bin\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Program Files (x86)\apache-ant-1.9.16\bin;C:\Program Files\CMake\bin;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\7-Zip;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\gawk-3.1.6-1-bin\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin;C:\Users\Martin\AppData\Local\Microsoft\WindowsApps;C:\Users\Martin\AppData\Local\atom\bin;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Users\Martin\.dotnet\tools > > > > USERNAME=Martin > > > > OS=Windows_NT > > > > PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 140 Stepping 1, GenuineIntel > > > > --------------- S Y S T E M --------------- > > > > OS: > > > > Windows 10 , 64 bit Build 19041 (10.0.19041.1348) > > > > OS uptime: 0 days 4:15 hours > > > > Hyper-V role detected > > > > CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 6 model 140 stepping 1 microcode 0x86, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, avx512f, avx512dq, avx512cd, avx512bw, avx512vl, sha, fma, vzeroupper, avx512_vpopcntdq, avx512_vpclmulqdq, avx512_vaes, avx512_vnni, clflush, clflushopt, clwb, avx512_vbmi2, avx512_vbmi, hv > > > > Memory: 4k page, system-wide physical 16107M (6064M free) > > > > TotalPageFile size 20971M (AvailPageFile size 8500M) > > > > current process WorkingSet (physical memory assigned to process): 136M, peak: 147M > > > > current process commit charge ("private bytes"): 177M, peak: 191M > > > > vm_info: OpenJDK 64-Bit Server VM (17-panama+3-167) for windows-amd64 JRE (17-panama+3-167), built on May 18 2021 13:10:19 by "mach5one" with MS VC++ 16.8 (VS2019) > > > > END. > > > > Sent with ProtonMail Secure Email. > > > > ??????? Original Message ??????? > > > > Le vendredi 12 novembre 2021 ? 15:47, Martin Pernollet martin.pernollet at protonmail.com a ?crit : > > > > > Thanks Jon, > > > > > > MinGW did not create a GL.dll file but rather libfreeglut.dll so I changed to > > > > > > public class glut_h extends glut_h_3 { > > > > > > static { > > > > > > System.loadLibrary("libfreeglut"); > > > > > > But it still fails, this time due to unresolved dependencies. Dependency Walker reveals tons of unreachable DLL (see screenshot). > > > > > > This failed attempt is documented here https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/issues/11;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI_ssFZQS$ > > > > > > I'll follow your suggestion and update documentation and notify you once I got it working. > > > > > > ??????? Original Message ??????? > > > > > > Le vendredi 12 novembre 2021 ? 15:17, Jorn Vernee jorn.vernee at oracle.com a ?crit : > > > > > > > Hi Martin, > > > > > > > > Thanks for testing this! > > > > > > > > The UnsatisfiedLinkError is not from code looking for a header file, > > > > > > > > it's from looking for a library/.dll file named GL.dll. On Windows > > > > > > > > though, freeglut needs the opengl libraries that come bundled with > > > > > > > > Windows (found in C:\Windows\System32), named opengl32 and glu32. The > > > > > > > > script should already add -l flags for those. > > > > > > > > WRT the jextract error you see. > > > > > > > > I have not tried to run the sample with freeglut installed through MingW > > > > > > > > yet. I instead used the freeglut package for MSVC here: > > > > > > > > https://urldefense.com/v3/https://www.transmissionzero.co.uk/software/freeglut-devel/;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI2nUkNV_$ extracted > > > > > > > > that in some folder, and the pointed freeglutPath at that folder. > > > > > > > > Note that jextract is using clang underneath to do the parsing. I know > > > > > > > > clang works pretty well with MSVC/Windows SDK header files, but I'm > > > > > > > > guessing it can not understand the MingW headers, looking at your error. > > > > > > > > I think it's having problems with __MINGW_NOTHROW and > > > > > > > > __MINGW_ATTRIB_NORETURN, which look like compiler builtins. > > > > > > > > I'd suggest trying the freeglut package I linked to instead, together > > > > > > > > with the Windows SDK headers (which clang should find automatically), > > > > > > > > and taking MingW headers out of the equation for now. We should probably > > > > > > > > create a README for that sample to include instructions on how to get > > > > > > > > freeglut. > > > > > > > > Note that on top of that, you will also have to change Teapot.java to > > > > > > > > account for a change in parameter names resulting in slightly different > > > > > > > > code being generated by jextract [1]. > > > > > > > > HTH, > > > > > > > > Jorn > > > > > > > > [1] : > > > > > > > > diff --git a/opengl/Teapot.java b/opengl/Teapot.java > > > > > > > > index 22d1f44..d5eb786 100644 > > > > > > > > --- a/opengl/Teapot.java > > > > > > > > +++ b/opengl/Teapot.java > > > > > > > > @@ -79,8 +79,8 @@ public class Teapot { > > > > > > > > glutInitWindowSize(500, 500); > > > > > > > > glutCreateWindow(allocator.allocateUtf8String("Hello Panama!")); > > > > > > > > var teapot = new Teapot(allocator); > > > > > > > > -??????????? var displayStub = > > > > > > > > glutDisplayFunc$func.allocate(teapot::display, scope); > > > > > > > > -??????????? var idleStub = glutIdleFunc$func.allocate(teapot::onIdle, > > > > > > > > scope); > > > > > > > > +??????????? var displayStub = > > > > > > > > glutDisplayFunc$callback.allocate(teapot::display, scope); > > > > > > > > +??????????? var idleStub = > > > > > > > > glutIdleFunc$callback.allocate(teapot::onIdle, scope); > > > > > > > > glutDisplayFunc(displayStub); > > > > > > > > glutIdleFunc(idleStub); > > > > > > > > glutMainLoop(); > > > > > > > > On 12/11/2021 13:01, Martin Pernollet wrote: > > > > > > > > > Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows : > > > > > > > > > > public class glut_h extends glut_h_3 { > > > > > > > > > > static { > > > > > > > > > > System.loadLibrary("GL"); > > > > > > > > > > System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT"); > > > > > > > > > > } > > > > > > > > > > while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW. > > > > > > > > > > Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir. > > > > > > > > > > So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception : > > > > > > > > > > PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1 > > > > > > > > > > [...] > > > > > > > > > > freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32 > > > > > > > > > > WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract > > > > > > > > > > C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator > > > > > > > > > > ERROR: jextract exited with non-zero exit code: 3 > > > > > > > > > > Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 : > > > > > > > > > > 358: #ifndef _CRT_TERMINATE_DEFINED > > > > > > > > > > 359: #define _CRT_TERMINATE_DEFINED > > > > > > > > > > 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; > > > > > > > > > > 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN; > > > > > > > > > > I should mention that > > > > > > > > > > - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct. > > > > > - I verified GCC and G++ are callable from Powershell > > > > > - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself. > > > > > > > > > > Is this stdlib error something some of you already faced? How did you fix? > > > > > > > > > > Thanks! > > > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > > > ??????? Original Message ??????? > > > > > > > > > > Le lundi 18 octobre 2021 ? 11:29, Rado Smogura mail at smogura.eu a ?crit : > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > Let me answer the last questions about JExtract and .h files for every > > > > > > > > > > > > platform. > > > > > > > > > > > > It may be needed to do separate bindings, unless you can prove > > > > > > > > > > > > otherwise. The specifications provides .h files and names, but may not > > > > > > > > > > > > be clear if, > > > > > > > > > > > > - given name is variable, or define > > > > > > > > > > > > - values set to const / variable > > > > > > > > > > > > - expr() is method or define > > > > > > > > > > > > There was one experiment with POSIX, where even so standard things like > > > > > > > > > > > > net may differ on values assigned to DEFINED between Linux & OSX. > > > > > > > > > > > > Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other, > > > > > > > > > > > > and this values will be "inlined" into extracted code. > > > > > > > > > > > > However how exactly is with OpenGL I don't know. > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > Rado > > > > > > > > > > > > On 17.10.2021 15:20, Martin Pernollet wrote: > > > > > > > > > > > > > > > > > > > Report about more intensive use of foreign function API > > > > > > > > > > > > > > I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn?t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow : > > > > > > > > > > > > > > void onIdle() { > > > > > > > > > > > > > > throw new IllegalArgumentException("Teapot does not support coffee"); > > > > > > > > > > > > > > } > > > > > > > > > > > > > > My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412. > > > > > > > > > > > > > > I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before. > > > > > > > > > > > > > > Integration in an AWT Canvas > > > > > > > > > > > > > > Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU. > > > > > > > > > > > > > > It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc. > > > > > > > > > > > > > > I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL. > > > > > > > > > > > > > > Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) > > > > > > > > > > > > > > I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way). > > > > > > > > > > > > > > More practical questions about JExtract > > > > > > > > > > > > > > I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case. > > > > > > > > > > > > > > Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM? > > > > > > > > > > > > > > Thanks for reading! > > > > > > > > > > > > > > Martin > > > > > > > > > > > > > > [0] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8bHkQ00p$ > > > > > > > > > > > > > > [1] https://urldefense.com/v3/https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8ROseeEa$ > > > > > > > > > > > > > > [2] https://urldefense.com/v3/https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8WkFrawU$ From jorn.vernee at oracle.com Fri Nov 12 16:00:57 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 12 Nov 2021 17:00:57 +0100 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> Message-ID: Unfortunately, the process of publishing an EA takes a bit of time, so it's done infrequently. There will probably another EA after the next JEP integration into JDK 18 (should be somewhere in the next 3 months if all goes well (yeah...)). In the future we also hope to make the process of building easier by moving jextract to a standalone repo. Then it should just be a simple gradlew call to get a working jextract (which would depend on the vanilla JDK). Jorn On 12/11/2021 16:50, Martin Pernollet wrote: > Yes, I used Build 17-panama+3-167 (2021/5/18) and the fix you mention was merged later. > > Do you have an idea of when the next Panama EA build will be made available online? Building JDK myself looks like an interesting experience but I fear it will take me lot of time. > > Martin > > > > Sent with ProtonMail Secure Email. > > ??????? Original Message ??????? > > Le vendredi 12 novembre 2021 ? 16:25, Jorn Vernee a ?crit : > >> Hi Martin, >> >> This looks like a case of: https://urldefense.com/v3/__https://github.com/openjdk/jdk17/pull/35__;!!ACWV5N9M2RV99hQ!fguI6QniMKRKnma71X7d7YOA4me6TUT0MG0JnhFFBlrU1HXLCbjtAuYTVErAiAr_$ >> >> Are you using the panama snapshot from jdk.java.net? That snapshot >> >> doesn't contain the fix AFAIK. The samples are also made for the latest >> >> panama-foreign API, so they won't work with the snapshot (at least not >> >> out of the box). >> >> I think the only solution to the crash is to build the >> >> panama-foreign/foreign-jextract branch yourself. >> >> Sorry, >> >> Jorn >> >> On 12/11/2021 16:09, Martin Pernollet wrote: >> >>> When I now try with the precompiled freeglut you suggest I got a jextract crash. My exact command was >>> >>> C:\Program" "Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe `-I "C:\\Users\\Martin\\Dev\\jzy3d\\external\\freeglut\\include"` >>> >>> "-l" opengl32 `"-l" glu32` >>> >>> "-l" freeglut `"-t" "opengl"` >>> >>> "--" ` >>> >>> "C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h" >>> >>> And the core dump file says >>> >>> A fatal error has been detected by the Java Runtime Environment: >>> ================================================================ >>> >>> Internal Error (codeBuffer.cpp:972), pid=8664, tid=17112 >>> ======================================================== >>> >>> guarantee(sect->end() <= tend) failed: sanity >>> ============================================= >>> >>> JRE version: OpenJDK Runtime Environment (17.0+3) (build 17-panama+3-167) >>> ========================================================================= >>> >>> Java VM: OpenJDK 64-Bit Server VM (17-panama+3-167, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) >>> ============================================================================================================================================== >>> >>> No core dump will be written. Minidumps are not enabled by default on client versions of Windows >>> ================================================================================================ >>> >>> If you would like to submit a bug report, please visit: >>> ======================================================= >>> >>> https://urldefense.com/v3/https://bugreport.java.com/bugreport/crash.jsp;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI5KK9Rju$ >>> ============================================================================================================================================================ >>> >>> --------------- S U M M A R Y ------------ >>> >>> Command Line: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h >>> >>> Host: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 8 cores, 15G, Windows 10 , 64 bit Build 19041 (10.0.19041.1348) >>> >>> Time: Fri Nov 12 16:06:50 2021 Europe de l , 64 bit Build 19041 (10.0.19041.1348) elapsed time: 0.603555 seconds (0d 0h 0m 0s) >>> >>> --------------- T H R E A D --------------- >>> >>> Current thread (0x000001beaa55be10): JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] >>> >>> Stack: [0x0000003933800000,0x0000003933900000] >>> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>> >>> V [jvm.dll+0x668f4a] >>> >>> V [jvm.dll+0x7c69a9] >>> >>> V [jvm.dll+0x7c814e] >>> >>> V [jvm.dll+0x7c8757] >>> >>> V [jvm.dll+0x23ec9c] >>> >>> V [jvm.dll+0x1f92d0] >>> >>> V [jvm.dll+0x795431] >>> >>> V [jvm.dll+0x792fa9] >>> >>> C 0x000001beb1dfd661 >>> >>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >>> >>> j jdk.internal.foreign.abi.ProgrammableUpcallHandler.allocateOptimizedUpcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/ABIDescriptor;Ljdk/internal/foreign/abi/ProgrammableUpcallHandler$CallRegs;)J+0 jdk.incubator.foreign at 17-panama >>> >>> j jdk.internal.foreign.abi.ProgrammableUpcallHandler.make(Ljdk/internal/foreign/abi/ABIDescriptor;Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/CallingSequence;)Ljdk/internal/foreign/abi/UpcallHandler;+380 jdk.incubator.foreign at 17-panama >>> >>> j jdk.internal.foreign.abi.x64.windows.CallArranger.arrangeUpcall(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;Ljdk/incubator/foreign/FunctionDescriptor;)Ljdk/internal/foreign/abi/UpcallHandler;+28 jdk.incubator.foreign at 17-panama >>> >>> j jdk.internal.foreign.abi.x64.windows.Windowsx64Linker.upcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/incubator/foreign/FunctionDescriptor;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+35 jdk.incubator.foreign at 17-panama >>> >>> j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+34 jdk.incubator.jextract at 17-panama >>> >>> j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;)Ljdk/incubator/foreign/MemoryAddress;+7 jdk.incubator.jextract at 17-panama >>> >>> j jdk.internal.clang.libclang.CXCursorVisitor.allocate(Ljdk/internal/clang/libclang/CXCursorVisitor;)Ljdk/incubator/foreign/MemoryAddress;+8 jdk.incubator.jextract at 17-panama >>> >>> j jdk.internal.clang.Cursor$CursorChildren.()V+15 jdk.incubator.jextract at 17-panama >>> >>> v ~StubRoutines::call_stub >>> >>> j jdk.internal.clang.Cursor.children()Ljava/util/stream/Stream;+1 jdk.incubator.jextract at 17-panama >>> >>> j jdk.internal.jextract.impl.Parser.parse(Ljava/nio/file/Path;Ljava/util/Collection;)Ljdk/incubator/jextract/Declaration$Scoped;+66 jdk.incubator.jextract at 17-panama >>> >>> j jdk.incubator.jextract.JextractTool.parse(Ljava/util/List;[Ljava/lang/String;)Ljdk/incubator/jextract/Declaration$Scoped;+55 jdk.incubator.jextract at 17-panama >>> >>> j jdk.incubator.jextract.JextractTool.run([Ljava/lang/String;)I+904 jdk.incubator.jextract at 17-panama >>> >>> j jdk.incubator.jextract.JextractTool.main([Ljava/lang/String;)V+46 jdk.incubator.jextract at 17-panama >>> >>> v ~StubRoutines::call_stub >>> >>> --------------- P R O C E S S --------------- >>> >>> Threads class SMR info: >>> >>> _java_thread_list=0x000001bece7196e0, length=13, elements={ >>> >>> 0x000001beaa55be10, 0x000001becd023240, 0x000001becd023e00, 0x000001becd0394b0, >>> >>> 0x000001becd03a070, 0x000001becd03ea50, 0x000001becd03f410, 0x000001becd0401b0, >>> >>> 0x000001becd041400, 0x000001becd042e10, 0x000001becdc945a0, 0x000001becdcab950, >>> >>> 0x000001becdf7e080 >>> >>> } >>> >>> Java Threads: ( => current thread ) >>> >>> =>0x000001beaa55be10 JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] >>> >>> 0x000001becd023240 JavaThread "Reference Handler" daemon [_thread_blocked, id=16356, stack(0x0000003933f00000,0x0000003934000000)] >>> >>> 0x000001becd023e00 JavaThread "Finalizer" daemon [_thread_blocked, id=6204, stack(0x0000003934000000,0x0000003934100000)] >>> >>> 0x000001becd0394b0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=972, stack(0x0000003934100000,0x0000003934200000)] >>> >>> 0x000001becd03a070 JavaThread "Attach Listener" daemon [_thread_blocked, id=2084, stack(0x0000003934200000,0x0000003934300000)] >>> >>> 0x000001becd03ea50 JavaThread "Service Thread" daemon [_thread_blocked, id=18128, stack(0x0000003934300000,0x0000003934400000)] >>> >>> 0x000001becd03f410 JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=3404, stack(0x0000003934400000,0x0000003934500000)] >>> >>> 0x000001becd0401b0 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=10160, stack(0x0000003934500000,0x0000003934600000)] >>> >>> 0x000001becd041400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=15728, stack(0x0000003934600000,0x0000003934700000)] >>> >>> 0x000001becd042e10 JavaThread "Sweeper thread" daemon [_thread_blocked, id=3932, stack(0x0000003934700000,0x0000003934800000)] >>> >>> 0x000001becdc945a0 JavaThread "Notification Thread" daemon [_thread_blocked, id=12368, stack(0x0000003934800000,0x0000003934900000)] >>> >>> 0x000001becdcab950 JavaThread "Common-Cleaner" daemon [_thread_blocked, id=15996, stack(0x0000003934a00000,0x0000003934b00000)] >>> >>> 0x000001becdf7e080 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=8236, stack(0x0000003934e00000,0x0000003934f00000)] >>> >>> Other Threads: >>> >>> 0x000001becd01c730 VMThread "VM Thread" [stack: 0x0000003933e00000,0x0000003933f00000] [id=8136] >>> >>> 0x000001becd00d9b0 WatcherThread [stack: 0x0000003934900000,0x0000003934a00000] [id=11228] >>> >>> 0x000001beaa5a9a40 GCTaskThread "GC Thread#0" [stack: 0x0000003933900000,0x0000003933a00000] [id=15472] >>> >>> 0x000001becde6f060 GCTaskThread "GC Thread#1" [stack: 0x0000003934b00000,0x0000003934c00000] [id=9408] >>> >>> 0x000001becde782a0 GCTaskThread "GC Thread#2" [stack: 0x0000003934c00000,0x0000003934d00000] [id=15952] >>> >>> 0x000001becde78560 GCTaskThread "GC Thread#3" [stack: 0x0000003934d00000,0x0000003934e00000] [id=17212] >>> >>> 0x000001bece9140e0 GCTaskThread "GC Thread#4" [stack: 0x0000003934f00000,0x0000003935000000] [id=13940] >>> >>> 0x000001bece914ea0 GCTaskThread "GC Thread#5" [stack: 0x0000003935000000,0x0000003935100000] [id=12744] >>> >>> 0x000001beaa5ba550 ConcurrentGCThread "G1 Main Marker" [stack: 0x0000003933a00000,0x0000003933b00000] [id=9236] >>> >>> 0x000001beaa5bbf70 ConcurrentGCThread "G1 Conc#0" [stack: 0x0000003933b00000,0x0000003933c00000] [id=17776] >>> >>> 0x000001beaa5e6a80 ConcurrentGCThread "G1 Refine#0" [stack: 0x0000003933c00000,0x0000003933d00000] [id=1088] >>> >>> 0x000001beaa5e84c0 ConcurrentGCThread "G1 Service" [stack: 0x0000003933d00000,0x0000003933e00000] [id=3248] >>> >>> Threads with active compile tasks: >>> >>> C2 CompilerThread0 608 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) >>> >>> VM state: not at safepoint (normal execution) >>> >>> VM Mutex/Monitor currently owned by a thread: None >>> >>> Heap address: 0x0000000704400000, size: 4028 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 >>> >>> CDS archive(s) mapped at: [0x0000000800000000-0x0000000800bb0000-0x0000000800bb0000), size 12255232, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. >>> >>> Compressed class space mapped at: 0x0000000800c00000-0x0000000840c00000, reserved size: 1073741824 >>> >>> Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 >>> >>> GC Precious Log: >>> >>> CPUs: 8 total, 8 available >>> >>> Memory: 16107M >>> >>> Large Page Support: Disabled >>> >>> NUMA Support: Disabled >>> >>> Compressed Oops: Enabled (Zero based) >>> >>> Heap Region Size: 2M >>> >>> Heap Min Capacity: 8M >>> >>> Heap Initial Capacity: 8M >>> >>> Heap Max Capacity: 4028M >>> >>> Pre-touch: Disabled >>> >>> Parallel Workers: 8 >>> >>> Concurrent Workers: 2 >>> >>> Concurrent Refinement Workers: 8 >>> >>> Periodic GC: Disabled >>> >>> Heap: >>> >>> garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 2 young (4096K), 1 survivors (2048K) >>> >>> Metaspace used 4346K, committed 5056K, reserved 1056768K >>> >>> class space used 589K, committed 896K, reserved 1048576K >>> >>> Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts), HC=humongous(continues), CS=collection set, F=free, OA=open archive, CA=closed archive, TAMS=top-at-mark-start (previous, next) >>> >>> | 0|0x0000000704400000, 0x00000007044e4e00, 0x0000000704600000| 44%| O| |TAMS 0x0000000704400000, 0x0000000704400000| Untracked >>> >>> | 1|0x0000000704600000, 0x0000000704600000, 0x0000000704800000| 0%| F| |TAMS 0x0000000704600000, 0x0000000704600000| Untracked >>> >>> | 2|0x0000000704800000, 0x00000007048fb810, 0x0000000704a00000| 49%| S|CS|TAMS 0x0000000704800000, 0x0000000704800000| Complete >>> >>> | 3|0x0000000704a00000, 0x0000000704bfa230, 0x0000000704c00000| 98%| E| |TAMS 0x0000000704a00000, 0x0000000704a00000| Complete >>> >>> Card table byte_map: [0x000001bec1900000,0x000001bec20e0000] _byte_map_base: 0x000001bebe0de000 >>> >>> Marking Bits (Prev, Next): (CMBitMap*) 0x000001beaa5aa060, (CMBitMap*) 0x000001beaa5aa0a0 >>> >>> Prev Bits: [0x000001bec28c0000, 0x000001bec67b0000) >>> >>> Next Bits: [0x000001bec67b0000, 0x000001beca6a0000) >>> >>> Polling page: 0x000001bea8380000 >>> >>> Metaspace: >>> >>> Usage: >>> >>> Non-class: 3.67 MB used. >>> >>> Class: 589.17 KB used. >>> >>> Both: 4.24 MB used. >>> >>> Virtual space: >>> >>> Non-class space: 8.00 MB reserved, 4.06 MB ( 51%) committed, 1 nodes. >>> >>> Class space: 1.00 GB reserved, 896.00 KB ( <1%) committed, 1 nodes. >>> >>> Both: 1.01 GB reserved, 4.94 MB ( <1%) committed. >>> >>> Chunk freelists: >>> >>> Non-Class: 2.55 MB >>> >>> Class: 2.96 MB >>> >>> Both: 5.51 MB >>> >>> MaxMetaspaceSize: unlimited >>> >>> CompressedClassSpaceSize: 1.00 GB >>> >>> Initial GC threshold: 21.00 MB >>> >>> Current GC threshold: 21.00 MB >>> >>> CDS: on >>> >>> MetaspaceReclaimPolicy: balanced >>> >>> - commit_granule_bytes: 65536. >>> - commit_granule_words: 8192. >>> - virtual_space_node_default_size: 1048576. >>> - enlarge_chunks_in_place: 1. >>> - new_chunks_are_fully_committed: 0. >>> - uncommit_free_chunks: 1. >>> - use_allocation_guard: 0. >>> - handle_deallocations: 1. >>> >>> Internal statistics: >>> >>> num_allocs_failed_limit: 0. >>> >>> num_arena_births: 990. >>> >>> num_arena_deaths: 0. >>> >>> num_vsnodes_births: 2. >>> >>> num_vsnodes_deaths: 0. >>> >>> num_space_committed: 79. >>> >>> num_space_uncommitted: 0. >>> >>> num_chunks_returned_to_freelist: 0. >>> >>> num_chunks_taken_from_freelist: 1166. >>> >>> num_chunk_merges: 0. >>> >>> num_chunk_splits: 758. >>> >>> num_chunks_enlarged: 370. >>> >>> num_purges: 0. >>> >>> CodeHeap 'non-profiled nmethods': size=120000Kb used=542Kb max_used=542Kb free=119458Kb >>> >>> bounds [0x000001beb98c0000, 0x000001beb9b30000, 0x000001bec0df0000] >>> >>> CodeHeap 'profiled nmethods': size=120000Kb used=1537Kb max_used=1537Kb free=118462Kb >>> >>> bounds [0x000001beb2390000, 0x000001beb2600000, 0x000001beb98c0000] >>> >>> CodeHeap 'non-nmethods': size=5760Kb used=1214Kb max_used=1246Kb free=4545Kb >>> >>> bounds [0x000001beb1df0000, 0x000001beb2060000, 0x000001beb2390000] >>> >>> total_blobs=1537 nmethods=1035 adapters=412 >>> >>> compilation: enabled >>> >>> stopped_count=0, restarted_count=0 >>> >>> full_count=0 >>> >>> Compilation events (20 events): >>> >>> Event: 0.590 Thread 0x000001becd041400 1020 3 java.lang.invoke.DirectMethodHandle:: (148 bytes) >>> >>> Event: 0.591 Thread 0x000001becd0401b0 nmethod 1019 0x000001beb9945710 code [0x000001beb9945880, 0x000001beb9945958] >>> >>> Event: 0.591 Thread 0x000001becd041400 nmethod 1020 0x000001beb2508510 code [0x000001beb25087c0, 0x000001beb2509748] >>> >>> Event: 0.591 Thread 0x000001becd0401b0 1021 4 jdk.internal.org.objectweb.asm.Frame::getLocal (46 bytes) >>> >>> Event: 0.591 Thread 0x000001becd0401b0 nmethod 1021 0x000001beb9946010 code [0x000001beb9946180, 0x000001beb9946258] >>> >>> Event: 0.592 Thread 0x000001becd041400 1024 3 java.lang.invoke.LambdaFormEditor$TransformKey::of (51 bytes) >>> >>> Event: 0.593 Thread 0x000001becd041400 nmethod 1024 0x000001beb2509c90 code [0x000001beb2509e80, 0x000001beb250a448] >>> >>> Event: 0.593 Thread 0x000001becd041400 1025 3 java.lang.invoke.LambdaFormEditor$TransformKey::packedBytes (39 bytes) >>> >>> Event: 0.593 Thread 0x000001becd041400 nmethod 1025 0x000001beb250a610 code [0x000001beb250a7a0, 0x000001beb250a8b8] >>> >>> Event: 0.593 Thread 0x000001becdf7e080 1028 4 java.lang.invoke.LambdaForm$BasicType::basicType (19 bytes) >>> >>> Event: 0.593 Thread 0x000001becd0401b0 1029 4 jdk.internal.org.objectweb.asm.Frame::pop (42 bytes) >>> >>> Event: 0.593 Thread 0x000001becd041400 1031 3 java.lang.invoke.MethodHandles::collectArguments (47 bytes) >>> >>> Event: 0.593 Thread 0x000001becd0401b0 nmethod 1029 0x000001beb9946910 code [0x000001beb9946a80, 0x000001beb9946b58] >>> >>> Event: 0.593 Thread 0x000001becd0401b0 1030 4 jdk.internal.org.objectweb.asm.Frame::merge (317 bytes) >>> >>> Event: 0.593 Thread 0x000001becd041400 nmethod 1031 0x000001beb250a990 code [0x000001beb250abc0, 0x000001beb250b3e8] >>> >>> Event: 0.593 Thread 0x000001becd041400 1032 3 java.lang.invoke.MethodHandles::collectArgumentsChecks (124 bytes) >>> >>> Event: 0.594 Thread 0x000001becd0401b0 nmethod 1030 0x000001beb9946c10 code [0x000001beb9946d80, 0x000001beb9946e78] >>> >>> Event: 0.594 Thread 0x000001becd0401b0 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) >>> >>> Event: 0.594 Thread 0x000001becd041400 nmethod 1032 0x000001beb250b790 code [0x000001beb250bb00, 0x000001beb250d2b8] >>> >>> Event: 0.594 Thread 0x000001becd041400 1033 3 java.lang.invoke.LambdaFormEditor::collectArgumentsForm (169 bytes) >>> >>> GC Heap History (10 events): >>> >>> Event: 0.086 GC heap before >>> >>> {Heap before GC invocations=0 (full 0): >>> >>> garbage-first heap total 8192K, used 2048K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 0 survivors (0K) >>> >>> Metaspace used 1471K, committed 1664K, reserved 1056768K >>> >>> class space used 151K, committed 256K, reserved 1048576K >>> >>> } >>> >>> Event: 0.088 GC heap after >>> >>> {Heap after GC invocations=1 (full 0): >>> >>> garbage-first heap total 8192K, used 1168K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 1 survivors (2048K) >>> >>> Metaspace used 1471K, committed 1664K, reserved 1056768K >>> >>> class space used 151K, committed 256K, reserved 1048576K >>> >>> } >>> >>> Event: 0.135 GC heap before >>> >>> {Heap before GC invocations=1 (full 0): >>> >>> garbage-first heap total 8192K, used 3216K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 2 young (4096K), 1 survivors (2048K) >>> >>> Metaspace used 2586K, committed 2880K, reserved 1056768K >>> >>> class space used 297K, committed 448K, reserved 1048576K >>> >>> } >>> >>> Event: 0.137 GC heap after >>> >>> {Heap after GC invocations=2 (full 0): >>> >>> garbage-first heap total 8192K, used 1270K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 1 survivors (2048K) >>> >>> Metaspace used 2586K, committed 2880K, reserved 1056768K >>> >>> class space used 297K, committed 448K, reserved 1048576K >>> >>> } >>> >>> Event: 0.165 GC heap before >>> >>> {Heap before GC invocations=2 (full 0): >>> >>> garbage-first heap total 8192K, used 3318K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 2 young (4096K), 1 survivors (2048K) >>> >>> Metaspace used 2912K, committed 3328K, reserved 1056768K >>> >>> class space used 360K, committed 576K, reserved 1048576K >>> >>> } >>> >>> Event: 0.167 GC heap after >>> >>> {Heap after GC invocations=3 (full 0): >>> >>> garbage-first heap total 8192K, used 1460K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 1 survivors (2048K) >>> >>> Metaspace used 2912K, committed 3328K, reserved 1056768K >>> >>> class space used 360K, committed 576K, reserved 1048576K >>> >>> } >>> >>> Event: 0.366 GC heap before >>> >>> {Heap before GC invocations=3 (full 0): >>> >>> garbage-first heap total 8192K, used 3508K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 2 young (4096K), 1 survivors (2048K) >>> >>> Metaspace used 3240K, committed 3712K, reserved 1056768K >>> >>> class space used 418K, committed 640K, reserved 1048576K >>> >>> } >>> >>> Event: 0.368 GC heap after >>> >>> {Heap after GC invocations=4 (full 0): >>> >>> garbage-first heap total 8192K, used 1629K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 1 survivors (2048K) >>> >>> Metaspace used 3240K, committed 3712K, reserved 1056768K >>> >>> class space used 418K, committed 640K, reserved 1048576K >>> >>> } >>> >>> Event: 0.570 GC heap before >>> >>> {Heap before GC invocations=4 (full 0): >>> >>> garbage-first heap total 8192K, used 3677K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 2 young (4096K), 1 survivors (2048K) >>> >>> Metaspace used 4023K, committed 4608K, reserved 1056768K >>> >>> class space used 525K, committed 832K, reserved 1048576K >>> >>> } >>> >>> Event: 0.572 GC heap after >>> >>> {Heap after GC invocations=5 (full 0): >>> >>> garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 1 survivors (2048K) >>> >>> Metaspace used 4023K, committed 4608K, reserved 1056768K >>> >>> class space used 525K, committed 832K, reserved 1048576K >>> >>> } >>> >>> Deoptimization events (14 events): >>> >>> Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb98c3cac relative=0x000000000000020c >>> >>> Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb98c3cac method=java.lang.String.hashCode()I @ 42 c2 >>> >>> Event: 0.034 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb98c3cac sp=0x00000039338fe520 >>> >>> Event: 0.034 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe4b8 mode 2 >>> >>> Event: 0.122 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb23ab367 sp=0x00000039338fd790 >>> >>> Event: 0.122 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e46763 sp=0x00000039338fcbb0 mode 0 >>> >>> Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb990a7e0 relative=0x0000000000007740 >>> >>> Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb990a7e0 method=jdk.internal.org.objectweb.asm.Frame.execute(IILjdk/internal/org/objectweb/asm/Symbol;Ljdk/internal/org/objectweb/asm/SymbolTable;)V @ 1 c2 >>> >>> Event: 0.584 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb990a7e0 sp=0x00000039338fcef0 >>> >>> Event: 0.584 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fcea8 mode 2 >>> >>> Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffffcc fr.pc=0x000001beb9943df4 relative=0x0000000000000354 >>> >>> Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: reason=intrinsic_or_type_checked_inlining action=make_not_entrant pc=0x000001beb9943df4 method=java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; @ 35 c2 >>> >>> Event: 0.592 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb9943df4 sp=0x00000039338fe2b0 >>> >>> Event: 0.592 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe258 mode 2 >>> >>> Classes unloaded (0 events): >>> >>> No events >>> >>> Classes redefined (0 events): >>> >>> No events >>> >>> Internal exceptions (20 events): >>> >>> Event: 0.424 Thread 0x000001beaa55be10 Exception (0x0000000704b67fa8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.566 Thread 0x000001beaa55be10 Exception (0x0000000704ba0908) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.572 Thread 0x000001beaa55be10 Exception (0x0000000704a048c8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.574 Thread 0x000001beaa55be10 Exception (0x0000000704a359b8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.576 Thread 0x000001beaa55be10 Exception (0x0000000704a69260) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.578 Thread 0x000001beaa55be10 Exception (0x0000000704a85548) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.579 Thread 0x000001beaa55be10 Exception (0x0000000704a9b548) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.581 Thread 0x000001beaa55be10 Exception (0x0000000704ac7840) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.582 Thread 0x000001beaa55be10 Exception (0x0000000704acada8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b0f9a8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b13248) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.588 Thread 0x000001beaa55be10 Exception (0x0000000704b66608) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b69ec0) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b72a48) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b765d8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7a480) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7e200) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b99bd0) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b9d880) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.593 Thread 0x000001beaa55be10 Exception (0x0000000704bd0ae8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Events (20 events): >>> >>> Event: 0.423 loading class java/io/DeleteOnExitHook done >>> >>> Event: 0.423 loading class java/io/DeleteOnExitHook$1 >>> >>> Event: 0.424 loading class java/io/DeleteOnExitHook$1 done >>> >>> Event: 0.550 Thread 0x000001beceebb670 Thread exited: 0x000001beceebb670 >>> >>> Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef >>> >>> Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator >>> >>> Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator done >>> >>> Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef done >>> >>> Event: 0.551 loading class java/util/stream/Streams$2 >>> >>> Event: 0.551 loading class java/util/stream/Streams$2 done >>> >>> Event: 0.570 Executing VM operation: G1CollectForAllocation >>> >>> Event: 0.572 Executing VM operation: G1CollectForAllocation done >>> >>> Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator >>> >>> Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator >>> >>> Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator done >>> >>> Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator done >>> >>> Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler >>> >>> Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler done >>> >>> Event: 0.594 loading class java/lang/invoke/MethodHandle$1 >>> >>> Event: 0.594 loading class java/lang/invoke/MethodHandle$1 done >>> >>> Dynamic libraries: >>> >>> 0x00007ff670d20000 - 0x00007ff670d28000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe >>> >>> 0x00007fff63110000 - 0x00007fff63305000 C:\Windows\SYSTEM32\ntdll.dll >>> >>> 0x00007fff61a00000 - 0x00007fff61abe000 C:\Windows\System32\KERNEL32.DLL >>> >>> 0x00007fff60960000 - 0x00007fff60c28000 C:\Windows\System32\KERNELBASE.dll >>> >>> 0x00007fff60830000 - 0x00007fff60930000 C:\Windows\System32\ucrtbase.dll >>> >>> 0x00007fff567c0000 - 0x00007fff567d8000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jli.dll >>> >>> 0x00007fff57310000 - 0x00007fff5732a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\VCRUNTIME140.dll >>> >>> 0x00007fff629b0000 - 0x00007fff62b51000 C:\Windows\System32\USER32.dll >>> >>> 0x00007fff60f30000 - 0x00007fff60f52000 C:\Windows\System32\win32u.dll >>> >>> 0x00007fff61ac0000 - 0x00007fff61aeb000 C:\Windows\System32\GDI32.dll >>> >>> 0x00007fff45910000 - 0x00007fff45baa000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\COMCTL32.dll >>> >>> 0x00007fff60c30000 - 0x00007fff60d3b000 C:\Windows\System32\gdi32full.dll >>> >>> 0x00007fff62fd0000 - 0x00007fff6306e000 C:\Windows\System32\msvcrt.dll >>> >>> 0x00007fff610c0000 - 0x00007fff6115d000 C:\Windows\System32\msvcp_win.dll >>> >>> 0x00007fff61160000 - 0x00007fff61190000 C:\Windows\System32\IMM32.DLL >>> >>> 0x00007fff5b580000 - 0x00007fff5b58c000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\vcruntime140_1.dll >>> >>> 0x00007fff44fa0000 - 0x00007fff4502d000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\msvcp140.dll >>> >>> 0x00007ffefad70000 - 0x00007ffefb920000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server\jvm.dll >>> >>> 0x00007fff61ef0000 - 0x00007fff61f9c000 C:\Windows\System32\ADVAPI32.dll >>> >>> 0x00007fff61cf0000 - 0x00007fff61d8b000 C:\Windows\System32\sechost.dll >>> >>> 0x00007fff62b60000 - 0x00007fff62c8a000 C:\Windows\System32\RPCRT4.dll >>> >>> 0x00007fff61ee0000 - 0x00007fff61ee8000 C:\Windows\System32\PSAPI.DLL >>> >>> 0x00007fff2dc20000 - 0x00007fff2dc29000 C:\Windows\SYSTEM32\WSOCK32.dll >>> >>> 0x00007fff54b80000 - 0x00007fff54b8a000 C:\Windows\SYSTEM32\VERSION.dll >>> >>> 0x00007fff518e0000 - 0x00007fff51907000 C:\Windows\SYSTEM32\WINMM.dll >>> >>> 0x00007fff61bd0000 - 0x00007fff61c3b000 C:\Windows\System32\WS2_32.dll >>> >>> 0x00007fff5f060000 - 0x00007fff5f072000 C:\Windows\SYSTEM32\kernel.appcore.dll >>> >>> 0x00007fff5b500000 - 0x00007fff5b50a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jimage.dll >>> >>> 0x00007fff5e430000 - 0x00007fff5e614000 C:\Windows\SYSTEM32\DBGHELP.DLL >>> >>> 0x00007fff45170000 - 0x00007fff4519c000 C:\Windows\SYSTEM32\dbgcore.DLL >>> >>> 0x00007fff60d40000 - 0x00007fff60dc3000 C:\Windows\System32\bcryptPrimitives.dll >>> >>> 0x00007fff44f70000 - 0x00007fff44f95000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\java.dll >>> >>> 0x00007fff612c0000 - 0x00007fff619ff000 C:\Windows\System32\SHELL32.dll >>> >>> 0x00007fff5e620000 - 0x00007fff5edb0000 C:\Windows\SYSTEM32\windows.storage.dll >>> >>> 0x00007fff62650000 - 0x00007fff629a5000 C:\Windows\System32\combase.dll >>> >>> 0x00007fff60280000 - 0x00007fff602ae000 C:\Windows\SYSTEM32\Wldp.dll >>> >>> 0x00007fff61c40000 - 0x00007fff61ced000 C:\Windows\System32\SHCORE.dll >>> >>> 0x00007fff62f70000 - 0x00007fff62fc5000 C:\Windows\System32\shlwapi.dll >>> >>> 0x00007fff60770000 - 0x00007fff6078f000 C:\Windows\SYSTEM32\profapi.dll >>> >>> 0x00007fff44f10000 - 0x00007fff44f29000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\net.dll >>> >>> 0x00007fff5ada0000 - 0x00007fff5aeac000 C:\Windows\SYSTEM32\WINHTTP.dll >>> >>> 0x00007fff5ffe0000 - 0x00007fff6004a000 C:\Windows\system32\mswsock.dll >>> >>> 0x00007fff28650000 - 0x00007fff28665000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\nio.dll >>> >>> 0x00007ffeda3b0000 - 0x00007ffede7d1000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\libclang.dll >>> >>> 0x00007fff62ea0000 - 0x00007fff62f6d000 C:\Windows\System32\OLEAUT32.dll >>> >>> 0x00007fff61190000 - 0x00007fff612ba000 C:\Windows\System32\ole32.dll >>> >>> 0x00007fff5dac0000 - 0x00007fff5db5e000 C:\Windows\system32\uxtheme.dll >>> >>> 0x00007fff61e30000 - 0x00007fff61ed9000 C:\Windows\System32\clbcatq.dll >>> >>> 0x00007fff601d0000 - 0x00007fff601e8000 C:\Windows\SYSTEM32\CRYPTSP.dll >>> >>> 0x00007fff5f8c0000 - 0x00007fff5f8f4000 C:\Windows\system32\rsaenh.dll >>> >>> 0x00007fff60930000 - 0x00007fff60957000 C:\Windows\System32\bcrypt.dll >>> >>> 0x00007fff60730000 - 0x00007fff6075e000 C:\Windows\SYSTEM32\USERENV.dll >>> >>> 0x00007fff601f0000 - 0x00007fff601fc000 C:\Windows\SYSTEM32\CRYPTBASE.dll >>> >>> 0x00007fff5fc80000 - 0x00007fff5fcbb000 C:\Windows\SYSTEM32\IPHLPAPI.DLL >>> >>> 0x00007fff62550000 - 0x00007fff62558000 C:\Windows\System32\NSI.dll >>> >>> 0x00007fff55080000 - 0x00007fff55097000 C:\Windows\SYSTEM32\dhcpcsvc6.DLL >>> >>> 0x00007fff55060000 - 0x00007fff5507d000 C:\Windows\SYSTEM32\dhcpcsvc.DLL >>> >>> 0x00007fff5fcd0000 - 0x00007fff5fd9b000 C:\Windows\SYSTEM32\DNSAPI.dll >>> >>> dbghelp: loaded successfully - version: 4.0.5 - missing functions: none >>> >>> symbol engine: initialized successfully - sym options: 0x614 - pdb path: .;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin;C:\Windows\SYSTEM32;C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server >>> >>> VM Arguments: >>> >>> jvm_args: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract >>> >>> java_command: jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h >>> >>> java_class_path (initial): >>> >>> Launcher Type: SUN_STANDARD >>> >>> [Global flags] >>> >>> intx CICompilerCount = 4 {product} {ergonomic} >>> >>> uint ConcGCThreads = 2 {product} {ergonomic} >>> >>> uint G1ConcRefinementThreads = 8 {product} {ergonomic} >>> >>> size_t G1HeapRegionSize = 2097152 {product} {ergonomic} >>> >>> uintx GCDrainStackTargetSize = 64 {product} {ergonomic} >>> >>> size_t InitialHeapSize = 8388608 {product} {command line} >>> >>> size_t MarkStackSize = 4194304 {product} {ergonomic} >>> >>> size_t MaxHeapSize = 4223664128 {product} {ergonomic} >>> >>> size_t MaxNewSize = 2533359616 {product} {ergonomic} >>> >>> size_t MinHeapDeltaBytes = 2097152 {product} {ergonomic} >>> >>> size_t MinHeapSize = 8388608 {product} {command line} >>> >>> uintx NonNMethodCodeHeapSize = 5839372 {pd product} {ergonomic} >>> >>> uintx NonProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} >>> >>> uintx ProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} >>> >>> uintx ReservedCodeCacheSize = 251658240 {pd product} {ergonomic} >>> >>> bool SegmentedCodeCache = true {product} {ergonomic} >>> >>> size_t SoftMaxHeapSize = 4223664128 {manageable} {ergonomic} >>> >>> bool UseCompressedClassPointers = true {product lp64_product} {ergonomic} >>> >>> bool UseCompressedOops = true {product lp64_product} {ergonomic} >>> >>> bool UseG1GC = true {product} {ergonomic} >>> >>> bool UseLargePagesIndividualAllocation = false {pd product} {ergonomic} >>> >>> Logging: >>> >>> Log output configuration: >>> >>> #0: stdout all=warning uptime,level,tags >>> >>> #1: stderr all=off uptime,level,tags >>> >>> Environment Variables: >>> >>> JAVA_HOME=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 >>> >>> PATH=C:\Program Files\Zulu\zulu-11\bin\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Program Files (x86)\apache-ant-1.9.16\bin;C:\Program Files\CMake\bin;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\7-Zip;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\gawk-3.1.6-1-bin\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin;C:\Users\Martin\AppData\Local\Microsoft\WindowsApps;C:\Users\Martin\AppData\Local\atom\bin;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Users\Martin\.dotnet\tools >>> >>> USERNAME=Martin >>> >>> OS=Windows_NT >>> >>> PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 140 Stepping 1, GenuineIntel >>> >>> --------------- S Y S T E M --------------- >>> >>> OS: >>> >>> Windows 10 , 64 bit Build 19041 (10.0.19041.1348) >>> >>> OS uptime: 0 days 4:15 hours >>> >>> Hyper-V role detected >>> >>> CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 6 model 140 stepping 1 microcode 0x86, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, avx512f, avx512dq, avx512cd, avx512bw, avx512vl, sha, fma, vzeroupper, avx512_vpopcntdq, avx512_vpclmulqdq, avx512_vaes, avx512_vnni, clflush, clflushopt, clwb, avx512_vbmi2, avx512_vbmi, hv >>> >>> Memory: 4k page, system-wide physical 16107M (6064M free) >>> >>> TotalPageFile size 20971M (AvailPageFile size 8500M) >>> >>> current process WorkingSet (physical memory assigned to process): 136M, peak: 147M >>> >>> current process commit charge ("private bytes"): 177M, peak: 191M >>> >>> vm_info: OpenJDK 64-Bit Server VM (17-panama+3-167) for windows-amd64 JRE (17-panama+3-167), built on May 18 2021 13:10:19 by "mach5one" with MS VC++ 16.8 (VS2019) >>> >>> END. >>> >>> Sent with ProtonMail Secure Email. >>> >>> ??????? Original Message ??????? >>> >>> Le vendredi 12 novembre 2021 ? 15:47, Martin Pernollet martin.pernollet at protonmail.com a ?crit : >>> >>>> Thanks Jon, >>>> >>>> MinGW did not create a GL.dll file but rather libfreeglut.dll so I changed to >>>> >>>> public class glut_h extends glut_h_3 { >>>> >>>> static { >>>> >>>> System.loadLibrary("libfreeglut"); >>>> >>>> But it still fails, this time due to unresolved dependencies. Dependency Walker reveals tons of unreachable DLL (see screenshot). >>>> >>>> This failed attempt is documented here https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/issues/11;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI_ssFZQS$ >>>> >>>> I'll follow your suggestion and update documentation and notify you once I got it working. >>>> >>>> ??????? Original Message ??????? >>>> >>>> Le vendredi 12 novembre 2021 ? 15:17, Jorn Vernee jorn.vernee at oracle.com a ?crit : >>>> >>>>> Hi Martin, >>>>> >>>>> Thanks for testing this! >>>>> >>>>> The UnsatisfiedLinkError is not from code looking for a header file, >>>>> >>>>> it's from looking for a library/.dll file named GL.dll. On Windows >>>>> >>>>> though, freeglut needs the opengl libraries that come bundled with >>>>> >>>>> Windows (found in C:\Windows\System32), named opengl32 and glu32. The >>>>> >>>>> script should already add -l flags for those. >>>>> >>>>> WRT the jextract error you see. >>>>> >>>>> I have not tried to run the sample with freeglut installed through MingW >>>>> >>>>> yet. I instead used the freeglut package for MSVC here: >>>>> >>>>> https://urldefense.com/v3/https://www.transmissionzero.co.uk/software/freeglut-devel/;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI2nUkNV_$ extracted >>>>> >>>>> that in some folder, and the pointed freeglutPath at that folder. >>>>> >>>>> Note that jextract is using clang underneath to do the parsing. I know >>>>> >>>>> clang works pretty well with MSVC/Windows SDK header files, but I'm >>>>> >>>>> guessing it can not understand the MingW headers, looking at your error. >>>>> >>>>> I think it's having problems with __MINGW_NOTHROW and >>>>> >>>>> __MINGW_ATTRIB_NORETURN, which look like compiler builtins. >>>>> >>>>> I'd suggest trying the freeglut package I linked to instead, together >>>>> >>>>> with the Windows SDK headers (which clang should find automatically), >>>>> >>>>> and taking MingW headers out of the equation for now. We should probably >>>>> >>>>> create a README for that sample to include instructions on how to get >>>>> >>>>> freeglut. >>>>> >>>>> Note that on top of that, you will also have to change Teapot.java to >>>>> >>>>> account for a change in parameter names resulting in slightly different >>>>> >>>>> code being generated by jextract [1]. >>>>> >>>>> HTH, >>>>> >>>>> Jorn >>>>> >>>>> [1] : >>>>> >>>>> diff --git a/opengl/Teapot.java b/opengl/Teapot.java >>>>> >>>>> index 22d1f44..d5eb786 100644 >>>>> >>>>> --- a/opengl/Teapot.java >>>>> >>>>> +++ b/opengl/Teapot.java >>>>> >>>>> @@ -79,8 +79,8 @@ public class Teapot { >>>>> >>>>> glutInitWindowSize(500, 500); >>>>> >>>>> glutCreateWindow(allocator.allocateUtf8String("Hello Panama!")); >>>>> >>>>> var teapot = new Teapot(allocator); >>>>> >>>>> -??????????? var displayStub = >>>>> >>>>> glutDisplayFunc$func.allocate(teapot::display, scope); >>>>> >>>>> -??????????? var idleStub = glutIdleFunc$func.allocate(teapot::onIdle, >>>>> >>>>> scope); >>>>> >>>>> +??????????? var displayStub = >>>>> >>>>> glutDisplayFunc$callback.allocate(teapot::display, scope); >>>>> >>>>> +??????????? var idleStub = >>>>> >>>>> glutIdleFunc$callback.allocate(teapot::onIdle, scope); >>>>> >>>>> glutDisplayFunc(displayStub); >>>>> >>>>> glutIdleFunc(idleStub); >>>>> >>>>> glutMainLoop(); >>>>> >>>>> On 12/11/2021 13:01, Martin Pernollet wrote: >>>>> >>>>>> Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows : >>>>>> >>>>>> public class glut_h extends glut_h_3 { >>>>>> >>>>>> static { >>>>>> >>>>>> System.loadLibrary("GL"); >>>>>> >>>>>> System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT"); >>>>>> >>>>>> } >>>>>> >>>>>> while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW. >>>>>> >>>>>> Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir. >>>>>> >>>>>> So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception : >>>>>> >>>>>> PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1 >>>>>> >>>>>> [...] >>>>>> >>>>>> freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32 >>>>>> >>>>>> WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract >>>>>> >>>>>> C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator >>>>>> >>>>>> ERROR: jextract exited with non-zero exit code: 3 >>>>>> >>>>>> Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 : >>>>>> >>>>>> 358: #ifndef _CRT_TERMINATE_DEFINED >>>>>> >>>>>> 359: #define _CRT_TERMINATE_DEFINED >>>>>> >>>>>> 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; >>>>>> >>>>>> 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN; >>>>>> >>>>>> I should mention that >>>>>> >>>>>> - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct. >>>>>> - I verified GCC and G++ are callable from Powershell >>>>>> - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself. >>>>>> >>>>>> Is this stdlib error something some of you already faced? How did you fix? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Sent with ProtonMail Secure Email. >>>>>> >>>>>> ??????? Original Message ??????? >>>>>> >>>>>> Le lundi 18 octobre 2021 ? 11:29, Rado Smogura mail at smogura.eu a ?crit : >>>>>> >>>>>>> Hi Martin, >>>>>>> >>>>>>> Let me answer the last questions about JExtract and .h files for every >>>>>>> >>>>>>> platform. >>>>>>> >>>>>>> It may be needed to do separate bindings, unless you can prove >>>>>>> >>>>>>> otherwise. The specifications provides .h files and names, but may not >>>>>>> >>>>>>> be clear if, >>>>>>> >>>>>>> - given name is variable, or define >>>>>>> >>>>>>> - values set to const / variable >>>>>>> >>>>>>> - expr() is method or define >>>>>>> >>>>>>> There was one experiment with POSIX, where even so standard things like >>>>>>> >>>>>>> net may differ on values assigned to DEFINED between Linux & OSX. >>>>>>> >>>>>>> Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other, >>>>>>> >>>>>>> and this values will be "inlined" into extracted code. >>>>>>> >>>>>>> However how exactly is with OpenGL I don't know. >>>>>>> >>>>>>> Kind regards, >>>>>>> >>>>>>> Rado >>>>>>> >>>>>>> On 17.10.2021 15:20, Martin Pernollet wrote: >>>>>>> >>>>>>> >>>>>>>> Report about more intensive use of foreign function API >>>>>>>> >>>>>>>> I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn?t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow : >>>>>>>> >>>>>>>> void onIdle() { >>>>>>>> >>>>>>>> throw new IllegalArgumentException("Teapot does not support coffee"); >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412. >>>>>>>> >>>>>>>> I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before. >>>>>>>> >>>>>>>> Integration in an AWT Canvas >>>>>>>> >>>>>>>> Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU. >>>>>>>> >>>>>>>> It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc. >>>>>>>> >>>>>>>> I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL. >>>>>>>> >>>>>>>> Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) >>>>>>>> >>>>>>>> I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way). >>>>>>>> >>>>>>>> More practical questions about JExtract >>>>>>>> >>>>>>>> I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case. >>>>>>>> >>>>>>>> Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM? >>>>>>>> >>>>>>>> Thanks for reading! >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>> [0] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8bHkQ00p$ >>>>>>>> >>>>>>>> [1] https://urldefense.com/v3/https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8ROseeEa$ >>>>>>>> >>>>>>>> [2] https://urldefense.com/v3/https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8WkFrawU$ From duke at openjdk.java.net Fri Nov 12 18:00:54 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 12 Nov 2021 18:00:54 GMT Subject: [foreign-memaccess+abi] Integrated: Merge master In-Reply-To: <-hj--gWVgb1y9fP1rpkTvvy1oveNNTzhHVZ5GNA77jc=.d825add5-d395-4ddd-88c5-d88a5bb21e34@github.com> References: <-hj--gWVgb1y9fP1rpkTvvy1oveNNTzhHVZ5GNA77jc=.d825add5-d395-4ddd-88c5-d88a5bb21e34@github.com> Message-ID: On Fri, 12 Nov 2021 11:00:51 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 94 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following file contains merge conflicts: > > - src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-memaccess+abi > $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +105:openjdk-bot-105 > $ git checkout openjdk-bot-105 > > # Merge the target branch > $ git merge foreign-memaccess+abi > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-105:105 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke This pull request has now been integrated. Changeset: 0d3ad181 Author: J. Duke Committer: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/0d3ad18170c77ea160621f072b6d222722b410b4 Stats: 12027 lines in 460 files changed: 8492 ins; 1894 del; 1641 mod Merge master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/612 From duke at openjdk.java.net Fri Nov 12 18:10:14 2021 From: duke at openjdk.java.net (duke) Date: Fri, 12 Nov 2021 18:10:14 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 96 new changesets Message-ID: Changeset: 0616d868 Author: Magnus Ihse Bursie Date: 2021-11-05 12:05:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0616d868c7cd5010f017b315fa1cf6cc1617ce29 8276635: Use blessed modifier order in compiler code Reviewed-by: darcy ! src/java.compiler/share/classes/javax/tools/Diagnostic.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java Changeset: b9331360 Author: Magnus Ihse Bursie Date: 2021-11-05 12:06:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b9331360f50afe5b4549d7003d4932ebc54a3c71 8276641: Use blessed modifier order in jshell Reviewed-by: iris ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/AnsiWriter.java ! src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/WindowsAnsiWriter.java ! src/jdk.jshell/share/classes/jdk/jshell/Key.java ! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java ! src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java Changeset: 7023b3f8 Author: Magnus Ihse Bursie Date: 2021-11-05 12:07:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7023b3f8a120dda97bc27fdf130c05c1bd7a730b 8276628: Use blessed modifier order in serviceability code Reviewed-by: dholmes, lmesnik, cjplummer ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanServerDelegateImpl.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MXBeanProxy.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/HashedPasswordManager.java ! src/java.management/share/classes/javax/management/MBeanServerFactory.java ! src/java.management/share/classes/javax/management/ObjectName.java ! src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/java.management/share/classes/javax/management/timer/Timer.java ! src/java.management/share/classes/sun/management/ClassLoadingImpl.java ! src/java.management/share/classes/sun/management/NotificationEmitterSupport.java ! src/java.management/share/classes/sun/management/VMManagementImpl.java ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/aarch64/LinuxAARCH64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1MonitoringSupport.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionSetBase.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenCollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeapRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZAttachedArrayForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingEntry.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobals.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobalsForVMStructs.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGranuleMapForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGranuleMapForPageTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPage.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPageAllocator.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPageTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZRelocate.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZVirtualMemory.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DataLayout.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DefaultMetadataVisitor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ParametersTypeData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/SpeculativeTrapData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Node.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/InstanceConstructor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/tree/CTypeTreeNodeAdapter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java ! src/jdk.jdi/share/classes/com/sun/jdi/Bootstrap.java ! src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/Packet.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/PrimitiveValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TargetVM.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TypeComponentImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java ! src/jdk.management.agent/share/classes/sun/management/jdp/JdpJmxPacket.java ! src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java ! src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectorExtImpl.java ! src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java Changeset: c393ee8f Author: Magnus Ihse Bursie Date: 2021-11-05 14:09:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c393ee8f598850379266bdba1f55af94744dbad1 8276632: Use blessed modifier order in security-libs code Reviewed-by: mullan ! src/java.security.jgss/share/classes/sun/security/jgss/ProviderList.java ! src/java.security.jgss/share/classes/sun/security/jgss/TokenTracker.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/java.smartcardio/share/classes/javax/smartcardio/CardNotPresentException.java ! src/java.smartcardio/share/classes/javax/smartcardio/CardPermission.java ! src/java.smartcardio/share/classes/javax/smartcardio/TerminalFactory.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/ChannelImpl.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/PCSC.java ! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java ! src/java.smartcardio/windows/classes/sun/security/smartcardio/PlatformPCSC.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Constants.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKey.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CRSACipher.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CSignature.java Changeset: a74a839a Author: Vladimir Kozlov Date: 2021-11-05 16:07:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a74a839af02446d322d77c6e546e652ec6ad5d73 8276571: C2: pass compilation options as structure Reviewed-by: shade, chagedorn ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: 92d21763 Author: Daniel D. Daugherty Date: 2021-11-05 17:04:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92d2176362954a7093894057748056610eeafe4b 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 Reviewed-by: stuefe, gziemski ! src/hotspot/os/bsd/decoder_machO.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/share/runtime/os.cpp ! test/hotspot/gtest/runtime/test_os.cpp Changeset: b01f1073 Author: Brian Burkhalter Date: 2021-11-05 17:25:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b01f1073f9691c40fc15b7ed67ae2e019ff729ea 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error Reviewed-by: lancea ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: a4724332 Author: Andrew John Hughes Date: 2021-11-05 21:05:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a4724332098cd8bff44ee27e9190fd28fa5c1865 8276572: Fake libsyslookup.so library causes tooling issues Reviewed-by: shade, mcimadamore ! src/jdk.incubator.foreign/share/native/libsyslookup/syslookup.c Changeset: 0e0dd33f Author: Kim Barrett Date: 2021-11-05 21:20:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e0dd33fff9922a086968cfa6ccd27727f979c83 8276129: PretouchTask should page-align the chunk size Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/shared/pretouchTask.cpp Changeset: 59c3dcc7 Author: Magnus Ihse Bursie Date: 2021-11-05 21:21:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59c3dcc761ac7a9eab1517743cbb77e5526ca6f3 8276746: Add section on reproducible builds in building.md Reviewed-by: erikj, sgehwolf, aleonard ! doc/building.html ! doc/building.md Changeset: ed7ecca4 Author: Hamlin Li Date: 2021-11-05 23:24:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ed7ecca401e5f4c3c07dc98e05a21396c6cdf594 8254739: G1: Optimize evacuation failure for regions with few failed objects Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp ! src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp Changeset: c7095b20 Author: Anirvan Sarkar Committer: Joe Wang Date: 2021-11-06 00:41:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7095b20d956e154d9863a7928d26285f1a0a0ac 8276207: Properties.loadFromXML/storeToXML works incorrectly for supplementary characters Reviewed-by: joehw ! src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java ! src/java.base/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java ! test/jdk/java/util/Properties/LoadAndStoreXML.java Changeset: 2653cfbf Author: Jaikiran Pai Date: 2021-11-06 03:36:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2653cfbf0f316183ea23dd234896b44f7dd6eae0 8276688: Remove JLinkReproducibleXXXTest from ProblemList.txt Reviewed-by: alanb, mchung ! test/jdk/ProblemList.txt Changeset: 88491549 Author: Ioi Lam Date: 2021-11-07 21:38:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/884915496f7bfe754279f1644603131c64f192b3 8275846: read_base_archive_name() could read past the end of buffer Reviewed-by: ccheung, stuefe ! src/hotspot/share/cds/filemap.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java Changeset: 44047f84 Author: Yi Yang Date: 2021-11-08 02:18:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/44047f849fad157dac5df788aa5a2c1838e4aaf7 8274328: C2: Redundant CFG edges fixup in block ordering Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/block.cpp ! src/hotspot/share/opto/block.hpp Changeset: 3934fe54 Author: Nick Gasson Date: 2021-11-08 06:40:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3934fe54b4c3e51add6d3fe1f145e5aebfe3b2fc 8275847: Scheduling fails with "too many D-U pinch points" on small method Reviewed-by: thartmann, kvn ! src/hotspot/cpu/x86/vmreg_x86.hpp ! src/hotspot/share/opto/buildOopMap.cpp ! src/hotspot/share/opto/output.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestScheduleSmallMethod.java Changeset: fc0fe256 Author: Christian Stein Committer: Aleksey Shipilev Date: 2021-11-08 08:09:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc0fe256793b33430c1247e0c091150a091da3c4 8273235: tools/launcher/HelpFlagsTest.java Fails on Windows 32bit Reviewed-by: shade ! test/jdk/tools/launcher/HelpFlagsTest.java Changeset: d8b0dee6 Author: Ludvig Janiuk Committer: Claes Redestad Date: 2021-11-08 09:44:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8b0dee65e7e074d81eecf451542f79747ea7c78 8276239: Better tables in java.util.random package summary Reviewed-by: jlaskey ! src/java.base/share/classes/java/util/random/package-info.java Changeset: 0395e4ef Author: Hannes Walln?fer Date: 2021-11-08 11:35:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0395e4ef8ced8385cc2c9b3bea4c6f4490c62d2b 8276768: Snippet copy feature should use button instead of link Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java Changeset: 54481394 Author: Christian Hagedorn Date: 2021-11-08 12:47:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/54481394a3b7d36b2326e22e4aa910a3e8041b5c 8271056: C2: "assert(no_dead_loop) failed: dead loop detected" due to cmoving identity Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/cfgnode.cpp + test/hotspot/jtreg/compiler/c2/TestDeadDataLoopCmoveIdentity.java Changeset: ff6863c9 Author: Thomas Schatzl Date: 2021-11-08 12:59:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff6863c98dbd15c4f3920402eb0991727d1a380c 8276540: Howl Full CardSet container iteration marks too many cards Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp Changeset: 4c14eddf Author: Jan Lahoda Date: 2021-11-08 13:19:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c14eddf41f1d9984417dc5ac6aba6f268b31029 8274734: the method jdk.jshell.SourceCodeAnalysis documentation not working Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java + test/langtools/jdk/jshell/MultipleDocumentationTest.java Changeset: fa754b8f Author: Jan Lahoda Date: 2021-11-08 13:20:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa754b8ffda0ae16cda03d896260870ff8fb6ae9 8276149: jshell throws EOF error when throwing exception inside switch expression Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/langtools/jdk/jshell/CompletenessTest.java Changeset: 0c2d00bf Author: Jan Lahoda Date: 2021-11-08 13:21:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0c2d00bff7b96cca53820aadfdaf09c840a2a33a 8275097: Wrong span of the 'default' tag Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/parser/JavacParserTest.java ! test/langtools/tools/javac/patterns/SwitchErrors.out Changeset: cc2cac13 Author: Petr Portnov Committer: Roger Riggs Date: 2021-11-08 13:22:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cc2cac130cc28730a30d2e1d76bcb6ec8bc0b580 8274686: java.util.UUID#hashCode() should use Long.hashCode() Reviewed-by: rriggs ! src/java.base/share/classes/java/util/UUID.java Changeset: 71c4b195 Author: Andy Herrick Date: 2021-11-08 13:45:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/71c4b195178029f5414fa45d2c5ac70a1d2536e5 8276562: Fix to JDK-8263155 left out the help text changes Reviewed-by: asemenyuk, almatvee ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties Changeset: c815c5cb Author: Denghui Dong Date: 2021-11-08 14:30:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c815c5cbbb0b6a2aebd0a38cb930c74bd665d082 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) Reviewed-by: dholmes, coleenp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_Runtime1_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: ea23e733 Author: Daniel D. Daugherty Date: 2021-11-08 14:45:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea23e7333e03abb4aca3e9f3854bab418a4b70e2 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes Reviewed-by: coleenp, sspitsyn, dholmes, rehn ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEventController.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 7320b77b Author: Thomas Schatzl Date: 2021-11-08 15:00:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7320b77b3e451932ee8befa7af4b80593725761e 8276548: Use range based visitor for Howl-Full cards Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp Changeset: 75adf54b Author: Aleksey Shipilev Date: 2021-11-08 15:35:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/75adf54bdcc5e06fb8e8ca499a2f326d70b65f76 8276306: jdk/jshell/CustomInputToolBuilder.java fails intermittently on storage acquisition Reviewed-by: jlahoda ! test/langtools/jdk/jshell/CustomInputToolBuilder.java Changeset: 7e73bca0 Author: Roger Riggs Date: 2021-11-08 16:39:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e73bca0b7a34af9fb73780491951539815651b4 8276408: Deprecate Runtime.exec methods with a single string command line argument Reviewed-by: alanb ! src/java.base/share/classes/java/lang/Runtime.java ! test/jdk/java/lang/ProcessBuilder/Zombies.java ! test/jdk/java/lang/RuntimeTests/exec/BadEnvp.java ! test/jdk/java/lang/RuntimeTests/exec/ExecWithDir.java ! test/jdk/java/lang/RuntimeTests/exec/SetCwd.java Changeset: e383d263 Author: Jonathan Gibbons Date: 2021-11-08 19:13:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e383d263610c7b4d4be2dce599a9043b8f76cd64 8275199: Bogus warning generated for serializable records Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java = test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list Changeset: 905e3e88 Author: Eamonn McManus Date: 2021-11-08 19:57:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/905e3e88137d46f90de7034e9fc324e97af873a6 8231490: Ugly racy writes to ZipUtils.defaultBuf Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/Inflater.java Changeset: 14d66bd4 Author: Andrew Leonard Date: 2021-11-08 20:37:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14d66bd438dfa1feeafaca39be8f79a91e2968e9 8276654: element-list order is non deterministic Reviewed-by: ihse ! make/modules/jdk.javadoc/Gendata.gmk Changeset: a7dedb5f Author: Joe Darcy Date: 2021-11-08 22:19:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a7dedb5f4761a7d0bc4db658d96d369b13b80620 8276772: Refine javax.lang.model docs Reviewed-by: iris, vromero ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java ! src/java.compiler/share/classes/javax/lang/model/element/RecordComponentElement.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/type/NoType.java ! src/java.compiler/share/classes/javax/lang/model/type/NullType.java ! src/java.compiler/share/classes/javax/lang/model/type/PrimitiveType.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 38e6d5d6 Author: Bradford Wetmore Date: 2021-11-09 01:11:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38e6d5d6ed967f68e6ac1bfaa285efa16577c790 8276677: Malformed Javadoc inline tags in JDK source in javax/net/ssl Reviewed-by: jnimeh ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java Changeset: 8747882e Author: Ioi Lam Date: 2021-11-09 07:18:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8747882e4cb3af58062923bf830f9de877bdb03d 8276790: Rename GenericCDSFileMapHeader::_base_archive_path_offset Reviewed-by: dholmes, ccheung ! src/hotspot/share/cds/cdsConstants.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/include/cds.h ! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java Changeset: 945f4085 Author: Stefan Johansson Date: 2021-11-09 11:11:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/945f4085e5c51f37c2048bb221a1521895ba28c6 8276098: Do precise BOT updates in G1 evacuation phase Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Allocator.hpp ! src/hotspot/share/gc/g1/g1Allocator.inline.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/shared/plab.hpp Changeset: 5c7f77c8 Author: Thomas Schatzl Date: 2021-11-09 13:07:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5c7f77c82404976a6ca1d54b40f1969eac10d63b 8276850: Remove outdated comment in HeapRegionManager::par_iterate Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/heapRegionManager.cpp Changeset: 4bd5bfd8 Author: Thomas Stuefe Date: 2021-11-09 14:12:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4bd5bfd8e2624715ebfa6e4c49172361389fbc98 8276731: Metaspace chunks are uncommitted twice Reviewed-by: shade, coleenp ! src/hotspot/share/memory/metaspace/chunkManager.cpp Changeset: e1985947 Author: Masanori Yano Committer: Alan Bateman Date: 2021-11-09 14:28:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e198594753b0b0653256923586c7f4ec9e3cfac3 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Reviewed-by: mchung, alanb ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! test/jdk/java/lang/module/VersionTest.java Changeset: c27afb31 Author: Weijun Wang Date: 2021-11-09 14:46:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c27afb313b77d19e7ace7101c6f21aa5b2c56505 8276863: Remove test/jdk/sun/security/ec/ECDSAJavaVerify.java Reviewed-by: ascarpino - test/jdk/sun/security/ec/ECDSAJavaVerify.java Changeset: f65db88b Author: Yasumasa Suenaga Date: 2021-11-09 14:54:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f65db88b74911e5896d2ff536c4ac97e7f62d98b 8276841: Add support for Visual Studio 2022 Reviewed-by: erikj, ihse ! make/autoconf/toolchain_microsoft.m4 Changeset: e35abe32 Author: Hannes Walln?fer Date: 2021-11-09 15:05:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e35abe3235ab38985a19545e76c58260ec97c718 8256208: Javadoc's generated overview does not show classes of unnamed package Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java = test/langtools/jdk/javadoc/doclet/testUnnamedPackage/src1/pkg/D.java + test/langtools/jdk/javadoc/doclet/testUnnamedPackage/src1/pkg/package.html Changeset: 93692ea0 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-09 16:58:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/93692ea0a9bc437309b808f511c771a79dcdfb9a 8274395: Use enhanced-for instead of plain 'for' in jdk.internal.jvmstat Reviewed-by: cjplummer, amenkov, sspitsyn ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java Changeset: daf77ebf Author: Leo Korinth Date: 2021-11-09 17:50:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/daf77ebfc4ca6d537ef55acbd62b908b5575ad08 8276337: Use override specifier in HeapDumper Reviewed-by: stuefe, dholmes ! src/hotspot/share/services/heapDumper.cpp Changeset: dde959df Author: Brian Burkhalter Date: 2021-11-09 19:17:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dde959dfcef01897fdf51f820d414402e6309b8d 8276808: java/nio/channels/Channels/TransferTo.java timed out Reviewed-by: lancea, shade ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: a60e9125 Author: Pankaj Bansal Date: 2021-11-09 20:10:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a60e91259ba83d2a525b612b2c7a1fd7934b88a2 8198626: java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java Changeset: 055de6f5 Author: Hannes Walln?fer Date: 2021-11-09 20:11:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/055de6f566208b168818be1dc3ad29cdb9caa1cf 8223358: Incorrect HTML structure in annotation pages Reviewed-by: jjg + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeMemberWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeMemberWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeOptionalMemberWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AbstractMemberBuilder.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeMemberBuilder.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/pkg/AnnotationType.java Changeset: f9024d06 Author: Hannes Walln?fer Date: 2021-11-09 20:17:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f9024d0606e39863b590f0d7c949d569f8bf8abd 8230130: javadoc search result dialog shows cut off headers for long results Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Changeset: d7012fbd Author: Roger Riggs Date: 2021-11-09 20:43:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7012fbd604fc1a54a2d7364a6ca4a32f47ffc7c 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary Reviewed-by: alanb - test/jdk/java/lang/RuntimeTests/exec/ExecWithDir.java Changeset: 06992208 Author: Rickard B?ckman Date: 2021-11-09 21:38:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0699220830a457959b784b35af125b70f43fa3b0 8268882: C2: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Reviewed-by: neliasso, chagedorn, kvn ! src/hotspot/share/opto/postaloc.cpp Changeset: c8b0ee6b Author: Hamlin Li Date: 2021-11-10 01:12:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c8b0ee6b8a0c1bca8f8357e786f24c8cb6dd7310 8276833: G1: Make G1EvacFailureRegions::par_iterate const Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp Changeset: c1e41fe3 Author: Hamlin Li Date: 2021-11-10 01:13:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1e41fe38bbbae12e1f73d2cd63c7afffc19475b 8276842: G1: Only calculate size in bytes from words when needed Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailure.cpp Changeset: 8822d41f Author: Jamil Nimeh Date: 2021-11-10 01:24:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8822d41fdcc2c2d568badd72635dc587d21dbd63 8274736: Concurrent read/close of SSLSockets causes SSLSessions to be invalidated unnecessarily Reviewed-by: xuelei, wetmore ! src/java.base/share/classes/sun/security/ssl/TransportContext.java ! test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java + test/jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java Changeset: e91e9d85 Author: Hamlin Li Date: 2021-11-10 01:26:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e91e9d853272ea8f5ce490f2f0c971fd40795d74 8276721: G1: Refine G1EvacFailureObjectsSet::iterate Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp Changeset: 403f3185 Author: Anirvan Sarkar Committer: Christoph Langer Date: 2021-11-10 05:51:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/403f3185f0988dcf6ef4e857d6659533bfa2943f 8276854: Windows GHA builds fail due to broken Cygwin Reviewed-by: clanger ! .github/workflows/submit.yml Changeset: fd0a25e6 Author: Aleksey Shipilev Date: 2021-11-10 07:59:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd0a25e62b2c8abc3a419c2e80abbcf11c9e882f 8276805: java/awt/print/PrinterJob/CheckPrivilege.java fails due to disabled SecurityManager Reviewed-by: serb, aivanov ! test/jdk/java/awt/print/PrinterJob/CheckPrivilege.java Changeset: e01d6d00 Author: Prasanta Sadhukhan Date: 2021-11-10 08:34:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e01d6d00bc4ab5ca0d38f8894a78e6d911e0fe93 8276679: Malformed Javadoc inline tags in JDK source in javax/swing Reviewed-by: aivanov, pbansal ! src/java.desktop/share/classes/javax/swing/JTree.java ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java ! src/java.desktop/share/classes/javax/swing/event/HyperlinkEvent.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java Changeset: 0f463a7b Author: Aleksey Shipilev Date: 2021-11-10 09:50:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f463a7bf73791eda9404882ff63daf9040399bb 8276845: (fs) java/nio/file/spi/SetDefaultProvider.java fails on x86_32 Reviewed-by: alanb ! test/jdk/java/nio/file/spi/TestProvider.java Changeset: a3f710ef Author: Aleksey Shipilev Date: 2021-11-10 10:45:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a3f710efbe7dcef18477a96fd306bec19f181f8b 8276215: Intrinsics matchers should handle native method flags better Reviewed-by: dholmes, kvn ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp Changeset: a0b84453 Author: Aleksey Shipilev Date: 2021-11-10 11:27:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a0b84453b087ff368a32b93729c5b30fda22ed48 8276846: JDK-8273416 is incomplete for UseSSE=1 Reviewed-by: neliasso, kvn ! src/hotspot/cpu/x86/x86_32.ad Changeset: 0f23c6a9 Author: Sergey Tsypanov Committer: Claes Redestad Date: 2021-11-10 12:46:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0f23c6a9feb3657eb20ff5988a9e2ffca2108af1 8276926: Use String.valueOf() when initializing File.separator and File.pathSeparator Reviewed-by: redestad, jlaskey ! src/java.base/share/classes/java/io/File.java Changeset: 55b36c6f Author: Harold Seigel Date: 2021-11-10 13:11:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/55b36c6f3bb7eb066daaf41f9eba46633afedf08 8276825: hotspot/runtime/SelectionResolution test errors Reviewed-by: dholmes, shade ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/ClassBuilder.java ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/Clazz.java ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/TestBuilder.java Changeset: 38ec3a16 Author: Yasumasa Suenaga Date: 2021-11-10 14:33:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38ec3a16d722d740d0b2128c6f6c2d1eab7a7c08 8276672: Cannot build hsdis on WSL Co-authored-by: Magnus Ihse Bursie Co-authored-by: Yasumasa Suenaga Reviewed-by: ihse, erikj ! make/Hsdis.gmk Changeset: f561d3c1 Author: Aleksey Shipilev Date: 2021-11-10 14:41:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f561d3c1942ce901fa77c907839032f76feb6998 8276864: Update boot JDKs to 17.0.1 in GHA Reviewed-by: erikj, ihse ! make/conf/test-dependencies Changeset: ce3ed65a Author: Jonathan Gibbons Date: 2021-11-10 15:24:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce3ed65ac3411a533052a8c01231f7e540803afb 8273154: Provide a JavadocTester method for non-overlapping, unordered output matching Reviewed-by: prappo ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java + test/langtools/jdk/javadoc/testJavadocTester/TestJavadocTester.java Changeset: a5c160c7 Author: Weijun Wang Date: 2021-11-10 19:35:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5c160c711a3f66db18c75973f4efdea63332863 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs Reviewed-by: mullan ! src/java.base/share/classes/javax/security/auth/Subject.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java ! test/jdk/com/sun/security/sasl/gsskerb/AuthOnly.java ! test/jdk/com/sun/security/sasl/gsskerb/ConfSecurityLayer.java ! test/jdk/com/sun/security/sasl/gsskerb/NoSecurityLayer.java ! test/jdk/java/security/AccessController/PreserveCombiner.java + test/jdk/javax/security/auth/Subject/CurrentSubject.java ! test/jdk/javax/security/auth/Subject/DoAs.java + test/jdk/javax/security/auth/Subject/Exceptions.java + test/jdk/javax/security/auth/Subject/FromACC.java ! test/jdk/javax/security/auth/Subject/Synch.java ! test/jdk/sun/security/krb5/KrbCredSubKey.java ! test/jdk/sun/security/krb5/ServiceCredsCombination.java ! test/jdk/sun/security/krb5/auto/Context.java ! test/jdk/sun/security/krb5/auto/HttpNegotiateServer.java ! test/jdk/sun/security/krb5/auto/LongLife.java Changeset: 67c2714b Author: Coleen Phillimore Date: 2021-11-10 19:45:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67c2714ba2c9658e07153a6f50391c896e4caebc 8276889: Improve compatibility discussion in instanceKlass.cpp Reviewed-by: hseigel ! src/hotspot/share/oops/instanceKlass.cpp Changeset: 2374abda Author: Alisen Chung Committer: Alexey Ivanov Date: 2021-11-10 20:08:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2374abda19213d615a72c83f584ea61d5bbba4a3 8276678: Malformed Javadoc inline tags in JDK source in com/sun/beans/decoder/DocumentHandler.java Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/com/sun/beans/decoder/DocumentHandler.java Changeset: df02daa6 Author: Ioi Lam Date: 2021-11-10 20:22:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/df02daa6f9df801a7e0b6203fd6411d8a62bb277 8269986: Remove +3 from Symbol::identity_hash() Reviewed-by: coleenp ! src/hotspot/share/oops/symbol.hpp Changeset: 0c409cac Author: Naoto Sato Date: 2021-11-10 20:52:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0c409cac789f1b1d21e09a65db36bb6c72c569db 8276186: Require getAvailableLocales() methods to include Locale.ROOT Reviewed-by: prappo, smarks, iris ! src/java.base/share/classes/java/text/BreakIterator.java ! src/java.base/share/classes/java/text/Collator.java ! src/java.base/share/classes/java/text/DateFormat.java ! src/java.base/share/classes/java/text/DateFormatSymbols.java ! src/java.base/share/classes/java/text/DecimalFormatSymbols.java ! src/java.base/share/classes/java/text/NumberFormat.java ! src/java.base/share/classes/java/time/format/DecimalStyle.java ! src/java.base/share/classes/java/util/Calendar.java ! src/java.base/share/classes/java/util/Locale.java + test/jdk/java/util/Locale/RequiredAvailableLocalesTest.java Changeset: bce35ac1 Author: Naoto Sato Date: 2021-11-10 20:53:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bce35ac1d6c4115148468a3240ad459074e0b79e 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893 Reviewed-by: lancea, iris, bpb, scolebourne, rriggs ! src/java.base/share/classes/java/time/OffsetDateTime.java ! src/java.base/share/classes/java/time/ZonedDateTime.java Changeset: 73e6d7d7 Author: Zhengyu Gu Date: 2021-11-11 00:14:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/73e6d7d74d2ddd27f11775944c6fc4fb5268106d 8276801: gc/stress/CriticalNativeStress.java fails intermittently with Shenandoah Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp Changeset: e27a67a9 Author: Jesper Wilhelmsson Date: 2021-11-11 01:14:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e27a67a91647e584411a9ef57c0a028ab37af19b 8276930: Update ProblemList Reviewed-by: kevinw, dholmes ! test/jdk/ProblemList.txt Changeset: ad3be04d Author: Yoshiki Sato Committer: Naoto Sato Date: 2021-11-11 01:39:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ad3be04d2ac84836e393d696ff03ddfe72779094 8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766 Reviewed-by: naoto, coffeys ! src/java.base/share/classes/sun/util/resources/TimeZoneNames.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_de.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_es.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_fr.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_it.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ja.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ko.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_pt_BR.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_sv.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_CN.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_TW.java Changeset: 08e0fd67 Author: Hamlin Li Date: 2021-11-11 05:52:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/08e0fd6757ef15b71df0e86afd01211a6e48bd09 8276835: G1: make G1EvacFailureObjectsSet::record inline Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: 91bb0d65 Author: Aleksey Shipilev Date: 2021-11-11 07:07:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/91bb0d658bce010e74b248b56f0fa5b8a79e8802 8276796: gc/TestSystemGC.java large pages subtest fails with ZGC Reviewed-by: pliden, stefank ! test/hotspot/jtreg/gc/TestSystemGC.java Changeset: 7a140af2 Author: Christian Hagedorn Date: 2021-11-11 08:03:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a140af25362556ebe86147dcd74413e0044edc0 8276546: [IR Framework] Whitelist and ignore CompileThreshold Reviewed-by: kvn, neliasso ! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompileThreshold.java Changeset: 9862cd07 Author: Hannes Walln?fer Date: 2021-11-11 09:13:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9862cd07c162fcc9cd5cbdd0aab564f446f9256c 8275786: New javadoc option to add script files to generated documentation Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/langtools/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java + test/langtools/jdk/javadoc/doclet/testOptions/additional-script-1.js + test/langtools/jdk/javadoc/doclet/testOptions/additional-script-2.js ! test/langtools/jdk/javadoc/tool/CheckManPageOptions.java Changeset: aea09677 Author: casparcwang Committer: Hui Shi Date: 2021-11-11 10:39:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aea096770e74b9c0e1556467705ffdd6cf843d9d 8275854: C2: assert(stride_con != 0) failed: missed some peephole opt Co-authored-by: Roland Westrelin Reviewed-by: thartmann, roland, kvn ! src/hotspot/share/opto/ifnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestLoopEndNodeEliminate.java Changeset: c29cab8a Author: Tobias Hartmann Date: 2021-11-11 13:09:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c29cab8ab475055e02e4300f212907ff2db955ab 8276112: Inconsistent scalar replacement debug info at safepoints Reviewed-by: kvn, chagedorn ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/macro.hpp ! test/hotspot/jtreg/compiler/eliminateAutobox/TestIdentityWithEliminateBoxInDebugInfo.java + test/hotspot/jtreg/compiler/eliminateAutobox/TestSafepointDebugInfo.java Changeset: 2ca4ff87 Author: Aleksei Efimov Date: 2021-11-11 14:33:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ca4ff87b7c31d56542bbdcea70e828be33f4e97 8244202: Implementation of JEP 418: Internet-Address Resolution SPI Co-authored-by: Chris Hegarty Co-authored-by: Daniel Fuchs Co-authored-by: Alan Bateman Reviewed-by: dfuchs, alanb, michaelm, chegar ! src/java.base/share/classes/java/lang/RuntimePermission.java ! src/java.base/share/classes/java/net/Inet4AddressImpl.java ! src/java.base/share/classes/java/net/Inet6AddressImpl.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/InetAddressImpl.java ! src/java.base/share/classes/java/net/doc-files/net-properties.html + src/java.base/share/classes/java/net/spi/InetAddressResolver.java + src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java ! src/java.base/share/classes/java/net/spi/package-info.java ! src/java.base/share/classes/jdk/internal/access/JavaNetInetAddressAccess.java ! src/java.base/share/classes/module-info.java + src/java.base/share/classes/sun/net/ResolverProviderConfiguration.java ! src/java.base/share/native/libnet/InetAddress.c ! src/java.base/share/native/libnet/net_util.c ! src/java.base/share/native/libnet/net_util.h ! src/java.base/unix/native/libnet/Inet4AddressImpl.c ! src/java.base/unix/native/libnet/Inet6AddressImpl.c ! src/java.base/windows/native/libnet/Inet6AddressImpl.c + test/jdk/java/net/spi/InetAddressResolverProvider/AddressesCachingTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/BootstrapResolverUsageTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/BuiltInResolverTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/EmptyResultsStreamTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ForeverCache.props + test/jdk/java/net/spi/InetAddressResolverProvider/InetAddressUsageInGetProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/LookupPolicyMappingTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/LookupPolicyOfTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/NeverCache.props + test/jdk/java/net/spi/InetAddressResolverProvider/ProviderGetExceptionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ResolutionWithExceptionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ResolvePermissionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ReverseLookupDelegationTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/RuntimePermissionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/addresses.txt + test/jdk/java/net/spi/InetAddressResolverProvider/lib/test.library/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/lib/test.library/testlib/ResolutionRegistry.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/bootstrapUsage/bootstrap.usage.provider/impl/WithBootstrapResolverUsageProvider.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/bootstrapUsage/bootstrap.usage.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/delegating/delegating.provider/impl/DelegatingProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/delegating/delegating.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/empty/empty.results.provider/impl/EmptyResultsProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/empty/empty.results.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/faulty/faulty.provider/impl/FaultyResolverProviderGetImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/faulty/faulty.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/simple/simple.provider/impl/SimpleResolverProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/simple/simple.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/throwing/throwing.lookups.provider/impl/ThrowingLookupsProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/throwing/throwing.lookups.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/ClasspathProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/ClasspathResolverProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/META-INF/services/java.net.spi.InetAddressResolverProvider + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/addresses.txt + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/module/ModularProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/module/addresses.txt ! test/lib/jdk/test/lib/net/IPSupport.java Changeset: 5e98f993 Author: Ludvig Janiuk Committer: Alexey Ivanov Date: 2021-11-11 16:46:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e98f993b3cd68bb8564ea904f322235f55c4a7c 8276800: Fix table headers in NumericShaper.html Reviewed-by: naoto, aivanov ! src/java.desktop/share/classes/java/awt/font/NumericShaper.java Changeset: 6f35eede Author: Alexander Zvegintsev Date: 2021-11-11 16:53:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f35eede4576b6252544f553c3651312b024e7ea 8079267: [TEST_BUG] Test java/awt/Frame/MiscUndecorated/RepaintTest.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Frame/MiscUndecorated/RepaintTest.java Changeset: 8aae88b0 Author: Alan Bateman Date: 2021-11-11 19:07:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8aae88b0fc4acb76ef140f120712403cf4b04a46 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out" Reviewed-by: dfuchs ! test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java Changeset: b0d7a9da Author: Lance Andersen Date: 2021-11-11 19:09:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b0d7a9daa6ceb1959bc701043fe3f0397d2ba6f7 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp Reviewed-by: alanb ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: 0ca0acf6 Author: Claes Redestad Date: 2021-11-11 20:36:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ca0acf63cb5cec4c62a9948956a04822d6f74a5 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: 3445e50b Author: David Holmes Date: 2021-11-11 22:10:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3445e50bd573857660908a964886f94714315f4c 8276265: jcmd man page is outdated Reviewed-by: stuefe, cjplummer ! src/jdk.jcmd/share/man/jcmd.1 Changeset: 6954b98f Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-11 22:23:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6954b98f8faf29b6c2d13687a7a94e83302bdd85 8186670: Implement _onSpinWait() intrinsic for AArch64 Reviewed-by: phh, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp + src/hotspot/cpu/aarch64/spin_wait_aarch64.hpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64.java + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitNoneAArch64.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWait.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitProducerConsumer.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitSharedCounter.java Changeset: 1e941ded Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-11 22:26:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1e941dedad0ff6282ca4c1d2d71512974c97fc5e 8275197: Remove unused fields in ThaiBuddhistChronology Reviewed-by: naoto, rriggs, iris ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistChronology.java Changeset: 6b833db3 Author: Per Liden Date: 2021-11-12 08:19:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6b833db3f9cace8fbb09bb803ba31208e37a4622 8275329: ZGC: vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with assert(_phases->length() <= 1000) failed: Too many recored phases? Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/shared/gcTimer.cpp Changeset: 710f4964 Author: Nils Eliasson Date: 2021-11-12 10:08:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/710f496456d642c3e98d230270598f0b2dc75aba 8273277: C2: Move conditional negation into rc_predicate Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopopts/TestSkeletonPredicateNegation.java ! test/hotspot/jtreg/vmTestbase/jit/t/t105/t105.java Changeset: 4ae4c4ca Author: duke Date: 2021-11-12 11:00:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ae4c4cacd2ed8eaad42b052a23797e2073a57f3 Automatic merge of jdk:master into master Changeset: 0d3ad181 Author: J. Duke Committer: Jorn Vernee Date: 2021-11-12 17:57:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0d3ad18170c77ea160621f072b6d222722b410b4 Merge master ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/jdk/ProblemList.txt ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/jdk/ProblemList.txt Changeset: 45211848 Author: duke Date: 2021-11-12 17:58:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/45211848bce4c8d86688bc26a05f4c522ec8f4b8 Automatic merge of foreign-memaccess+abi into foreign-jextract ! src/java.base/share/classes/module-info.java ! test/jdk/tools/launcher/HelpFlagsTest.java ! src/java.base/share/classes/module-info.java ! test/jdk/tools/launcher/HelpFlagsTest.java From mcimadamore at openjdk.java.net Fri Nov 12 18:28:15 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 12 Nov 2021 18:28:15 GMT Subject: [foreign-jextract] RFR: 8277070: Regularize logic for cursor -> position conversion Message-ID: TreeMaker::toPos has the correct logic to extract a Position from a cursor, which avoids any potential NPEs. Unfortunately jextract code does not use it uniformly, especially `RecordLayoutComputer` and its subclasses. This patch turns the method into a static helper and makes the `CursorPosition` constructor private, so that other clients have to go through the static factory. ------------- Commit messages: - Turn helper function into a factory method in CursorPosition - Turn TreeMaker::toPos into a static helper. Changes: https://git.openjdk.java.net/panama-foreign/pull/613/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=613&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277070 Stats: 44 lines in 5 files changed: 12 ins; 15 del; 17 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/613.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/613/head:pull/613 PR: https://git.openjdk.java.net/panama-foreign/pull/613 From jvernee at openjdk.java.net Fri Nov 12 18:38:55 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 12 Nov 2021 18:38:55 GMT Subject: [foreign-jextract] RFR: 8277070: Regularize logic for cursor -> position conversion In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 18:14:27 GMT, Maurizio Cimadamore wrote: > TreeMaker::toPos has the correct logic to extract a Position from a cursor, which avoids any potential NPEs. Unfortunately jextract code does not use it uniformly, especially `RecordLayoutComputer` and its subclasses. This patch turns the method into a static helper and makes the `CursorPosition` constructor private, so that other clients have to go through the static factory. LGTM! ------------- Marked as reviewed by jvernee (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/613 From mcimadamore at openjdk.java.net Fri Nov 12 18:50:51 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 12 Nov 2021 18:50:51 GMT Subject: [foreign-jextract] Integrated: 8277070: Regularize logic for cursor -> position conversion In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 18:14:27 GMT, Maurizio Cimadamore wrote: > TreeMaker::toPos has the correct logic to extract a Position from a cursor, which avoids any potential NPEs. Unfortunately jextract code does not use it uniformly, especially `RecordLayoutComputer` and its subclasses. This patch turns the method into a static helper and makes the `CursorPosition` constructor private, so that other clients have to go through the static factory. This pull request has now been integrated. Changeset: 91bf4694 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/91bf46942faa8f7cac560874df1d3df52d5dc7dc Stats: 44 lines in 5 files changed: 12 ins; 15 del; 17 mod 8277070: Regularize logic for cursor -> position conversion Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/613 From psandoz at openjdk.java.net Fri Nov 12 19:06:11 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 12 Nov 2021 19:06:11 GMT Subject: [vectorIntrinsics+compress] RFR: Compress JavaDoc. Message-ID: Add a little summary of compress/expand in the cross-lane section of the `Vector` class doc. ------------- Commit messages: - Compress JavaDoc. Changes: https://git.openjdk.java.net/panama-vector/pull/162/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=162&range=00 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/162.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/162/head:pull/162 PR: https://git.openjdk.java.net/panama-vector/pull/162 From sviswanathan at openjdk.java.net Fri Nov 12 21:31:55 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 12 Nov 2021 21:31:55 GMT Subject: [vectorIntrinsics+compress] RFR: Compress JavaDoc. In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 19:00:44 GMT, Paul Sandoz wrote: > Add a little summary of compress/expand in the cross-lane section of the `Vector` class doc. Looks good to me. ------------- Marked as reviewed by sviswanathan (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/162 From john.r.rose at oracle.com Sat Nov 13 18:49:00 2021 From: john.r.rose at oracle.com (John Rose) Date: Sat, 13 Nov 2021 18:49:00 +0000 Subject: [vectorIntrinsics+compress] RFR: Compress JavaDoc. In-Reply-To: References: Message-ID: Good but in @code Mask should be VectorMask. > On Nov 12, 2021, at 1:32 PM, Sandhya Viswanathan wrote: > > ?On Fri, 12 Nov 2021 19:00:44 GMT, Paul Sandoz wrote: > >> Add a little summary of compress/expand in the cross-lane section of the `Vector` class doc. > > Looks good to me. > > ------------- > > Marked as reviewed by sviswanathan (Committer). > > PR: https://git.openjdk.java.net/panama-vector/pull/162 From john.r.rose at oracle.com Sun Nov 14 02:10:40 2021 From: john.r.rose at oracle.com (John Rose) Date: Sun, 14 Nov 2021 02:10:40 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> References: <3e7f733c-6bd8-d8b2-4c45-6b352d95311c@oracle.com> <2c532257-b23b-6a24-3a6d-c841619eb97b@oracle.com> <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> Message-ID: <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> On Oct 17, 2021, at 6:20 AM, Martin Pernollet > wrote: Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) I?m not an expert in AWT or graphics APIs but I do know a little about this history. First, 15-20 years is so long that you shouldn?t assume today?s conditions would be at all the same. Second, JOGL was built at a time when Sun had skunkworks projects investigating better native interoperation, similar in some ways to Panama, but Sun made a clear decision not to productize. At the time, JNI was seen by some as kind of defensive wall for Java. Now, not nearly so much. In fact, now Panama?s much more welcoming stance to native code is an important side to Java. Panama has been inspired, in part, by some of those old projects from 20 years ago. From martin.pernollet at protonmail.com Sun Nov 14 17:17:35 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Sun, 14 Nov 2021 17:17:35 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: =?us-ascii?Q?_<8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com>__<3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a=5Frexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=3D@protonmail.com>______?= Message-ID: Hi Jorn, I mainly understand from the fix that there was a memory size limit reached on my machine but not on yours when generating bindings. Do you think doubling this memory is a long term fix? Wouldn't it be better to be able to override the memory limit from an option, a bit like -Xmx.. ? ??????? Original Message ??????? Le vendredi 12 novembre 2021 ? 16:25, Jorn Vernee a ?crit : > Hi Martin, > > This looks like a case of: https://github.com/openjdk/jdk17/pull/35 > > Are you using the panama snapshot from jdk.java.net? That snapshot > > doesn't contain the fix AFAIK. The samples are also made for the latest > > panama-foreign API, so they won't work with the snapshot (at least not > > out of the box). > > I think the only solution to the crash is to build the > > panama-foreign/foreign-jextract branch yourself. > > Sorry, > > Jorn > > On 12/11/2021 16:09, Martin Pernollet wrote: > > > When I now try with the precompiled freeglut you suggest I got a jextract crash. My exact command was > > > > C:\Program" "Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe `-I "C:\\Users\\Martin\\Dev\\jzy3d\\external\\freeglut\\include"` > > > > "-l" opengl32 `"-l" glu32` > > > > "-l" freeglut `"-t" "opengl"` > > > > "--" ` > > > > "C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h" > > > > And the core dump file says > > > > A fatal error has been detected by the Java Runtime Environment: > > ================================================================ > > > > Internal Error (codeBuffer.cpp:972), pid=8664, tid=17112 > > ======================================================== > > > > guarantee(sect->end() <= tend) failed: sanity > > ============================================= > > > > JRE version: OpenJDK Runtime Environment (17.0+3) (build 17-panama+3-167) > > ========================================================================= > > > > Java VM: OpenJDK 64-Bit Server VM (17-panama+3-167, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) > > ============================================================================================================================================== > > > > No core dump will be written. Minidumps are not enabled by default on client versions of Windows > > ================================================================================================ > > > > If you would like to submit a bug report, please visit: > > ======================================================= > > > > https://urldefense.com/v3/https://bugreport.java.com/bugreport/crash.jsp;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI5KK9Rju$ > > ============================================================================================================================================================ > > > > --------------- S U M M A R Y ------------ > > > > Command Line: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h > > > > Host: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 8 cores, 15G, Windows 10 , 64 bit Build 19041 (10.0.19041.1348) > > > > Time: Fri Nov 12 16:06:50 2021 Europe de l , 64 bit Build 19041 (10.0.19041.1348) elapsed time: 0.603555 seconds (0d 0h 0m 0s) > > > > --------------- T H R E A D --------------- > > > > Current thread (0x000001beaa55be10): JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] > > > > Stack: [0x0000003933800000,0x0000003933900000] > > > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > > > > V [jvm.dll+0x668f4a] > > > > V [jvm.dll+0x7c69a9] > > > > V [jvm.dll+0x7c814e] > > > > V [jvm.dll+0x7c8757] > > > > V [jvm.dll+0x23ec9c] > > > > V [jvm.dll+0x1f92d0] > > > > V [jvm.dll+0x795431] > > > > V [jvm.dll+0x792fa9] > > > > C 0x000001beb1dfd661 > > > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > > > > j jdk.internal.foreign.abi.ProgrammableUpcallHandler.allocateOptimizedUpcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/ABIDescriptor;Ljdk/internal/foreign/abi/ProgrammableUpcallHandler$CallRegs;)J+0 jdk.incubator.foreign at 17-panama > > > > j jdk.internal.foreign.abi.ProgrammableUpcallHandler.make(Ljdk/internal/foreign/abi/ABIDescriptor;Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/CallingSequence;)Ljdk/internal/foreign/abi/UpcallHandler;+380 jdk.incubator.foreign at 17-panama > > > > j jdk.internal.foreign.abi.x64.windows.CallArranger.arrangeUpcall(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;Ljdk/incubator/foreign/FunctionDescriptor;)Ljdk/internal/foreign/abi/UpcallHandler;+28 jdk.incubator.foreign at 17-panama > > > > j jdk.internal.foreign.abi.x64.windows.Windowsx64Linker.upcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/incubator/foreign/FunctionDescriptor;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+35 jdk.incubator.foreign at 17-panama > > > > j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+34 jdk.incubator.jextract at 17-panama > > > > j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;)Ljdk/incubator/foreign/MemoryAddress;+7 jdk.incubator.jextract at 17-panama > > > > j jdk.internal.clang.libclang.CXCursorVisitor.allocate(Ljdk/internal/clang/libclang/CXCursorVisitor;)Ljdk/incubator/foreign/MemoryAddress;+8 jdk.incubator.jextract at 17-panama > > > > j jdk.internal.clang.Cursor$CursorChildren.()V+15 jdk.incubator.jextract at 17-panama > > > > v ~StubRoutines::call_stub > > > > j jdk.internal.clang.Cursor.children()Ljava/util/stream/Stream;+1 jdk.incubator.jextract at 17-panama > > > > j jdk.internal.jextract.impl.Parser.parse(Ljava/nio/file/Path;Ljava/util/Collection;)Ljdk/incubator/jextract/Declaration$Scoped;+66 jdk.incubator.jextract at 17-panama > > > > j jdk.incubator.jextract.JextractTool.parse(Ljava/util/List;[Ljava/lang/String;)Ljdk/incubator/jextract/Declaration$Scoped;+55 jdk.incubator.jextract at 17-panama > > > > j jdk.incubator.jextract.JextractTool.run([Ljava/lang/String;)I+904 jdk.incubator.jextract at 17-panama > > > > j jdk.incubator.jextract.JextractTool.main([Ljava/lang/String;)V+46 jdk.incubator.jextract at 17-panama > > > > v ~StubRoutines::call_stub > > > > --------------- P R O C E S S --------------- > > > > Threads class SMR info: > > > > _java_thread_list=0x000001bece7196e0, length=13, elements={ > > > > 0x000001beaa55be10, 0x000001becd023240, 0x000001becd023e00, 0x000001becd0394b0, > > > > 0x000001becd03a070, 0x000001becd03ea50, 0x000001becd03f410, 0x000001becd0401b0, > > > > 0x000001becd041400, 0x000001becd042e10, 0x000001becdc945a0, 0x000001becdcab950, > > > > 0x000001becdf7e080 > > > > } > > > > Java Threads: ( => current thread ) > > > > =>0x000001beaa55be10 JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] > > > > 0x000001becd023240 JavaThread "Reference Handler" daemon [_thread_blocked, id=16356, stack(0x0000003933f00000,0x0000003934000000)] > > > > 0x000001becd023e00 JavaThread "Finalizer" daemon [_thread_blocked, id=6204, stack(0x0000003934000000,0x0000003934100000)] > > > > 0x000001becd0394b0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=972, stack(0x0000003934100000,0x0000003934200000)] > > > > 0x000001becd03a070 JavaThread "Attach Listener" daemon [_thread_blocked, id=2084, stack(0x0000003934200000,0x0000003934300000)] > > > > 0x000001becd03ea50 JavaThread "Service Thread" daemon [_thread_blocked, id=18128, stack(0x0000003934300000,0x0000003934400000)] > > > > 0x000001becd03f410 JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=3404, stack(0x0000003934400000,0x0000003934500000)] > > > > 0x000001becd0401b0 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=10160, stack(0x0000003934500000,0x0000003934600000)] > > > > 0x000001becd041400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=15728, stack(0x0000003934600000,0x0000003934700000)] > > > > 0x000001becd042e10 JavaThread "Sweeper thread" daemon [_thread_blocked, id=3932, stack(0x0000003934700000,0x0000003934800000)] > > > > 0x000001becdc945a0 JavaThread "Notification Thread" daemon [_thread_blocked, id=12368, stack(0x0000003934800000,0x0000003934900000)] > > > > 0x000001becdcab950 JavaThread "Common-Cleaner" daemon [_thread_blocked, id=15996, stack(0x0000003934a00000,0x0000003934b00000)] > > > > 0x000001becdf7e080 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=8236, stack(0x0000003934e00000,0x0000003934f00000)] > > > > Other Threads: > > > > 0x000001becd01c730 VMThread "VM Thread" [stack: 0x0000003933e00000,0x0000003933f00000] [id=8136] > > > > 0x000001becd00d9b0 WatcherThread [stack: 0x0000003934900000,0x0000003934a00000] [id=11228] > > > > 0x000001beaa5a9a40 GCTaskThread "GC Thread#0" [stack: 0x0000003933900000,0x0000003933a00000] [id=15472] > > > > 0x000001becde6f060 GCTaskThread "GC Thread#1" [stack: 0x0000003934b00000,0x0000003934c00000] [id=9408] > > > > 0x000001becde782a0 GCTaskThread "GC Thread#2" [stack: 0x0000003934c00000,0x0000003934d00000] [id=15952] > > > > 0x000001becde78560 GCTaskThread "GC Thread#3" [stack: 0x0000003934d00000,0x0000003934e00000] [id=17212] > > > > 0x000001bece9140e0 GCTaskThread "GC Thread#4" [stack: 0x0000003934f00000,0x0000003935000000] [id=13940] > > > > 0x000001bece914ea0 GCTaskThread "GC Thread#5" [stack: 0x0000003935000000,0x0000003935100000] [id=12744] > > > > 0x000001beaa5ba550 ConcurrentGCThread "G1 Main Marker" [stack: 0x0000003933a00000,0x0000003933b00000] [id=9236] > > > > 0x000001beaa5bbf70 ConcurrentGCThread "G1 Conc#0" [stack: 0x0000003933b00000,0x0000003933c00000] [id=17776] > > > > 0x000001beaa5e6a80 ConcurrentGCThread "G1 Refine#0" [stack: 0x0000003933c00000,0x0000003933d00000] [id=1088] > > > > 0x000001beaa5e84c0 ConcurrentGCThread "G1 Service" [stack: 0x0000003933d00000,0x0000003933e00000] [id=3248] > > > > Threads with active compile tasks: > > > > C2 CompilerThread0 608 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) > > > > VM state: not at safepoint (normal execution) > > > > VM Mutex/Monitor currently owned by a thread: None > > > > Heap address: 0x0000000704400000, size: 4028 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 > > > > CDS archive(s) mapped at: [0x0000000800000000-0x0000000800bb0000-0x0000000800bb0000), size 12255232, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. > > > > Compressed class space mapped at: 0x0000000800c00000-0x0000000840c00000, reserved size: 1073741824 > > > > Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 > > > > GC Precious Log: > > > > CPUs: 8 total, 8 available > > > > Memory: 16107M > > > > Large Page Support: Disabled > > > > NUMA Support: Disabled > > > > Compressed Oops: Enabled (Zero based) > > > > Heap Region Size: 2M > > > > Heap Min Capacity: 8M > > > > Heap Initial Capacity: 8M > > > > Heap Max Capacity: 4028M > > > > Pre-touch: Disabled > > > > Parallel Workers: 8 > > > > Concurrent Workers: 2 > > > > Concurrent Refinement Workers: 8 > > > > Periodic GC: Disabled > > > > Heap: > > > > garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > > > Metaspace used 4346K, committed 5056K, reserved 1056768K > > > > class space used 589K, committed 896K, reserved 1048576K > > > > Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts), HC=humongous(continues), CS=collection set, F=free, OA=open archive, CA=closed archive, TAMS=top-at-mark-start (previous, next) > > > > | 0|0x0000000704400000, 0x00000007044e4e00, 0x0000000704600000| 44%| O| |TAMS 0x0000000704400000, 0x0000000704400000| Untracked > > > > | 1|0x0000000704600000, 0x0000000704600000, 0x0000000704800000| 0%| F| |TAMS 0x0000000704600000, 0x0000000704600000| Untracked > > > > | 2|0x0000000704800000, 0x00000007048fb810, 0x0000000704a00000| 49%| S|CS|TAMS 0x0000000704800000, 0x0000000704800000| Complete > > > > | 3|0x0000000704a00000, 0x0000000704bfa230, 0x0000000704c00000| 98%| E| |TAMS 0x0000000704a00000, 0x0000000704a00000| Complete > > > > Card table byte_map: [0x000001bec1900000,0x000001bec20e0000] _byte_map_base: 0x000001bebe0de000 > > > > Marking Bits (Prev, Next): (CMBitMap*) 0x000001beaa5aa060, (CMBitMap*) 0x000001beaa5aa0a0 > > > > Prev Bits: [0x000001bec28c0000, 0x000001bec67b0000) > > > > Next Bits: [0x000001bec67b0000, 0x000001beca6a0000) > > > > Polling page: 0x000001bea8380000 > > > > Metaspace: > > > > Usage: > > > > Non-class: 3.67 MB used. > > > > Class: 589.17 KB used. > > > > Both: 4.24 MB used. > > > > Virtual space: > > > > Non-class space: 8.00 MB reserved, 4.06 MB ( 51%) committed, 1 nodes. > > > > Class space: 1.00 GB reserved, 896.00 KB ( <1%) committed, 1 nodes. > > > > Both: 1.01 GB reserved, 4.94 MB ( <1%) committed. > > > > Chunk freelists: > > > > Non-Class: 2.55 MB > > > > Class: 2.96 MB > > > > Both: 5.51 MB > > > > MaxMetaspaceSize: unlimited > > > > CompressedClassSpaceSize: 1.00 GB > > > > Initial GC threshold: 21.00 MB > > > > Current GC threshold: 21.00 MB > > > > CDS: on > > > > MetaspaceReclaimPolicy: balanced > > > > - commit_granule_bytes: 65536. > > - commit_granule_words: 8192. > > - virtual_space_node_default_size: 1048576. > > - enlarge_chunks_in_place: 1. > > - new_chunks_are_fully_committed: 0. > > - uncommit_free_chunks: 1. > > - use_allocation_guard: 0. > > - handle_deallocations: 1. > > > > Internal statistics: > > > > num_allocs_failed_limit: 0. > > > > num_arena_births: 990. > > > > num_arena_deaths: 0. > > > > num_vsnodes_births: 2. > > > > num_vsnodes_deaths: 0. > > > > num_space_committed: 79. > > > > num_space_uncommitted: 0. > > > > num_chunks_returned_to_freelist: 0. > > > > num_chunks_taken_from_freelist: 1166. > > > > num_chunk_merges: 0. > > > > num_chunk_splits: 758. > > > > num_chunks_enlarged: 370. > > > > num_purges: 0. > > > > CodeHeap 'non-profiled nmethods': size=120000Kb used=542Kb max_used=542Kb free=119458Kb > > > > bounds [0x000001beb98c0000, 0x000001beb9b30000, 0x000001bec0df0000] > > > > CodeHeap 'profiled nmethods': size=120000Kb used=1537Kb max_used=1537Kb free=118462Kb > > > > bounds [0x000001beb2390000, 0x000001beb2600000, 0x000001beb98c0000] > > > > CodeHeap 'non-nmethods': size=5760Kb used=1214Kb max_used=1246Kb free=4545Kb > > > > bounds [0x000001beb1df0000, 0x000001beb2060000, 0x000001beb2390000] > > > > total_blobs=1537 nmethods=1035 adapters=412 > > > > compilation: enabled > > > > stopped_count=0, restarted_count=0 > > > > full_count=0 > > > > Compilation events (20 events): > > > > Event: 0.590 Thread 0x000001becd041400 1020 3 java.lang.invoke.DirectMethodHandle:: (148 bytes) > > > > Event: 0.591 Thread 0x000001becd0401b0 nmethod 1019 0x000001beb9945710 code [0x000001beb9945880, 0x000001beb9945958] > > > > Event: 0.591 Thread 0x000001becd041400 nmethod 1020 0x000001beb2508510 code [0x000001beb25087c0, 0x000001beb2509748] > > > > Event: 0.591 Thread 0x000001becd0401b0 1021 4 jdk.internal.org.objectweb.asm.Frame::getLocal (46 bytes) > > > > Event: 0.591 Thread 0x000001becd0401b0 nmethod 1021 0x000001beb9946010 code [0x000001beb9946180, 0x000001beb9946258] > > > > Event: 0.592 Thread 0x000001becd041400 1024 3 java.lang.invoke.LambdaFormEditor$TransformKey::of (51 bytes) > > > > Event: 0.593 Thread 0x000001becd041400 nmethod 1024 0x000001beb2509c90 code [0x000001beb2509e80, 0x000001beb250a448] > > > > Event: 0.593 Thread 0x000001becd041400 1025 3 java.lang.invoke.LambdaFormEditor$TransformKey::packedBytes (39 bytes) > > > > Event: 0.593 Thread 0x000001becd041400 nmethod 1025 0x000001beb250a610 code [0x000001beb250a7a0, 0x000001beb250a8b8] > > > > Event: 0.593 Thread 0x000001becdf7e080 1028 4 java.lang.invoke.LambdaForm$BasicType::basicType (19 bytes) > > > > Event: 0.593 Thread 0x000001becd0401b0 1029 4 jdk.internal.org.objectweb.asm.Frame::pop (42 bytes) > > > > Event: 0.593 Thread 0x000001becd041400 1031 3 java.lang.invoke.MethodHandles::collectArguments (47 bytes) > > > > Event: 0.593 Thread 0x000001becd0401b0 nmethod 1029 0x000001beb9946910 code [0x000001beb9946a80, 0x000001beb9946b58] > > > > Event: 0.593 Thread 0x000001becd0401b0 1030 4 jdk.internal.org.objectweb.asm.Frame::merge (317 bytes) > > > > Event: 0.593 Thread 0x000001becd041400 nmethod 1031 0x000001beb250a990 code [0x000001beb250abc0, 0x000001beb250b3e8] > > > > Event: 0.593 Thread 0x000001becd041400 1032 3 java.lang.invoke.MethodHandles::collectArgumentsChecks (124 bytes) > > > > Event: 0.594 Thread 0x000001becd0401b0 nmethod 1030 0x000001beb9946c10 code [0x000001beb9946d80, 0x000001beb9946e78] > > > > Event: 0.594 Thread 0x000001becd0401b0 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) > > > > Event: 0.594 Thread 0x000001becd041400 nmethod 1032 0x000001beb250b790 code [0x000001beb250bb00, 0x000001beb250d2b8] > > > > Event: 0.594 Thread 0x000001becd041400 1033 3 java.lang.invoke.LambdaFormEditor::collectArgumentsForm (169 bytes) > > > > GC Heap History (10 events): > > > > Event: 0.086 GC heap before > > > > {Heap before GC invocations=0 (full 0): > > > > garbage-first heap total 8192K, used 2048K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 0 survivors (0K) > > > > Metaspace used 1471K, committed 1664K, reserved 1056768K > > > > class space used 151K, committed 256K, reserved 1048576K > > > > } > > > > Event: 0.088 GC heap after > > > > {Heap after GC invocations=1 (full 0): > > > > garbage-first heap total 8192K, used 1168K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > > > Metaspace used 1471K, committed 1664K, reserved 1056768K > > > > class space used 151K, committed 256K, reserved 1048576K > > > > } > > > > Event: 0.135 GC heap before > > > > {Heap before GC invocations=1 (full 0): > > > > garbage-first heap total 8192K, used 3216K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > > > Metaspace used 2586K, committed 2880K, reserved 1056768K > > > > class space used 297K, committed 448K, reserved 1048576K > > > > } > > > > Event: 0.137 GC heap after > > > > {Heap after GC invocations=2 (full 0): > > > > garbage-first heap total 8192K, used 1270K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > > > Metaspace used 2586K, committed 2880K, reserved 1056768K > > > > class space used 297K, committed 448K, reserved 1048576K > > > > } > > > > Event: 0.165 GC heap before > > > > {Heap before GC invocations=2 (full 0): > > > > garbage-first heap total 8192K, used 3318K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > > > Metaspace used 2912K, committed 3328K, reserved 1056768K > > > > class space used 360K, committed 576K, reserved 1048576K > > > > } > > > > Event: 0.167 GC heap after > > > > {Heap after GC invocations=3 (full 0): > > > > garbage-first heap total 8192K, used 1460K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > > > Metaspace used 2912K, committed 3328K, reserved 1056768K > > > > class space used 360K, committed 576K, reserved 1048576K > > > > } > > > > Event: 0.366 GC heap before > > > > {Heap before GC invocations=3 (full 0): > > > > garbage-first heap total 8192K, used 3508K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > > > Metaspace used 3240K, committed 3712K, reserved 1056768K > > > > class space used 418K, committed 640K, reserved 1048576K > > > > } > > > > Event: 0.368 GC heap after > > > > {Heap after GC invocations=4 (full 0): > > > > garbage-first heap total 8192K, used 1629K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > > > Metaspace used 3240K, committed 3712K, reserved 1056768K > > > > class space used 418K, committed 640K, reserved 1048576K > > > > } > > > > Event: 0.570 GC heap before > > > > {Heap before GC invocations=4 (full 0): > > > > garbage-first heap total 8192K, used 3677K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 2 young (4096K), 1 survivors (2048K) > > > > Metaspace used 4023K, committed 4608K, reserved 1056768K > > > > class space used 525K, committed 832K, reserved 1048576K > > > > } > > > > Event: 0.572 GC heap after > > > > {Heap after GC invocations=5 (full 0): > > > > garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) > > > > region size 2048K, 1 young (2048K), 1 survivors (2048K) > > > > Metaspace used 4023K, committed 4608K, reserved 1056768K > > > > class space used 525K, committed 832K, reserved 1048576K > > > > } > > > > Deoptimization events (14 events): > > > > Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb98c3cac relative=0x000000000000020c > > > > Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb98c3cac method=java.lang.String.hashCode()I @ 42 c2 > > > > Event: 0.034 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb98c3cac sp=0x00000039338fe520 > > > > Event: 0.034 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe4b8 mode 2 > > > > Event: 0.122 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb23ab367 sp=0x00000039338fd790 > > > > Event: 0.122 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e46763 sp=0x00000039338fcbb0 mode 0 > > > > Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb990a7e0 relative=0x0000000000007740 > > > > Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb990a7e0 method=jdk.internal.org.objectweb.asm.Frame.execute(IILjdk/internal/org/objectweb/asm/Symbol;Ljdk/internal/org/objectweb/asm/SymbolTable;)V @ 1 c2 > > > > Event: 0.584 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb990a7e0 sp=0x00000039338fcef0 > > > > Event: 0.584 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fcea8 mode 2 > > > > Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffffcc fr.pc=0x000001beb9943df4 relative=0x0000000000000354 > > > > Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: reason=intrinsic_or_type_checked_inlining action=make_not_entrant pc=0x000001beb9943df4 method=java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; @ 35 c2 > > > > Event: 0.592 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb9943df4 sp=0x00000039338fe2b0 > > > > Event: 0.592 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe258 mode 2 > > > > Classes unloaded (0 events): > > > > No events > > > > Classes redefined (0 events): > > > > No events > > > > Internal exceptions (20 events): > > > > Event: 0.424 Thread 0x000001beaa55be10 Exception (0x0000000704b67fa8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.566 Thread 0x000001beaa55be10 Exception (0x0000000704ba0908) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.572 Thread 0x000001beaa55be10 Exception (0x0000000704a048c8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.574 Thread 0x000001beaa55be10 Exception (0x0000000704a359b8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.576 Thread 0x000001beaa55be10 Exception (0x0000000704a69260) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.578 Thread 0x000001beaa55be10 Exception (0x0000000704a85548) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.579 Thread 0x000001beaa55be10 Exception (0x0000000704a9b548) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.581 Thread 0x000001beaa55be10 Exception (0x0000000704ac7840) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.582 Thread 0x000001beaa55be10 Exception (0x0000000704acada8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b0f9a8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b13248) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.588 Thread 0x000001beaa55be10 Exception (0x0000000704b66608) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b69ec0) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b72a48) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b765d8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7a480) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7e200) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b99bd0) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b9d880) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Event: 0.593 Thread 0x000001beaa55be10 Exception (0x0000000704bd0ae8) > > > > thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] > > > > Events (20 events): > > > > Event: 0.423 loading class java/io/DeleteOnExitHook done > > > > Event: 0.423 loading class java/io/DeleteOnExitHook$1 > > > > Event: 0.424 loading class java/io/DeleteOnExitHook$1 done > > > > Event: 0.550 Thread 0x000001beceebb670 Thread exited: 0x000001beceebb670 > > > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef > > > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator > > > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator done > > > > Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef done > > > > Event: 0.551 loading class java/util/stream/Streams$2 > > > > Event: 0.551 loading class java/util/stream/Streams$2 done > > > > Event: 0.570 Executing VM operation: G1CollectForAllocation > > > > Event: 0.572 Executing VM operation: G1CollectForAllocation done > > > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator > > > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator > > > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator done > > > > Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator done > > > > Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler > > > > Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler done > > > > Event: 0.594 loading class java/lang/invoke/MethodHandle$1 > > > > Event: 0.594 loading class java/lang/invoke/MethodHandle$1 done > > > > Dynamic libraries: > > > > 0x00007ff670d20000 - 0x00007ff670d28000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe > > > > 0x00007fff63110000 - 0x00007fff63305000 C:\Windows\SYSTEM32\ntdll.dll > > > > 0x00007fff61a00000 - 0x00007fff61abe000 C:\Windows\System32\KERNEL32.DLL > > > > 0x00007fff60960000 - 0x00007fff60c28000 C:\Windows\System32\KERNELBASE.dll > > > > 0x00007fff60830000 - 0x00007fff60930000 C:\Windows\System32\ucrtbase.dll > > > > 0x00007fff567c0000 - 0x00007fff567d8000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jli.dll > > > > 0x00007fff57310000 - 0x00007fff5732a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\VCRUNTIME140.dll > > > > 0x00007fff629b0000 - 0x00007fff62b51000 C:\Windows\System32\USER32.dll > > > > 0x00007fff60f30000 - 0x00007fff60f52000 C:\Windows\System32\win32u.dll > > > > 0x00007fff61ac0000 - 0x00007fff61aeb000 C:\Windows\System32\GDI32.dll > > > > 0x00007fff45910000 - 0x00007fff45baa000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\COMCTL32.dll > > > > 0x00007fff60c30000 - 0x00007fff60d3b000 C:\Windows\System32\gdi32full.dll > > > > 0x00007fff62fd0000 - 0x00007fff6306e000 C:\Windows\System32\msvcrt.dll > > > > 0x00007fff610c0000 - 0x00007fff6115d000 C:\Windows\System32\msvcp_win.dll > > > > 0x00007fff61160000 - 0x00007fff61190000 C:\Windows\System32\IMM32.DLL > > > > 0x00007fff5b580000 - 0x00007fff5b58c000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\vcruntime140_1.dll > > > > 0x00007fff44fa0000 - 0x00007fff4502d000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\msvcp140.dll > > > > 0x00007ffefad70000 - 0x00007ffefb920000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server\jvm.dll > > > > 0x00007fff61ef0000 - 0x00007fff61f9c000 C:\Windows\System32\ADVAPI32.dll > > > > 0x00007fff61cf0000 - 0x00007fff61d8b000 C:\Windows\System32\sechost.dll > > > > 0x00007fff62b60000 - 0x00007fff62c8a000 C:\Windows\System32\RPCRT4.dll > > > > 0x00007fff61ee0000 - 0x00007fff61ee8000 C:\Windows\System32\PSAPI.DLL > > > > 0x00007fff2dc20000 - 0x00007fff2dc29000 C:\Windows\SYSTEM32\WSOCK32.dll > > > > 0x00007fff54b80000 - 0x00007fff54b8a000 C:\Windows\SYSTEM32\VERSION.dll > > > > 0x00007fff518e0000 - 0x00007fff51907000 C:\Windows\SYSTEM32\WINMM.dll > > > > 0x00007fff61bd0000 - 0x00007fff61c3b000 C:\Windows\System32\WS2_32.dll > > > > 0x00007fff5f060000 - 0x00007fff5f072000 C:\Windows\SYSTEM32\kernel.appcore.dll > > > > 0x00007fff5b500000 - 0x00007fff5b50a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jimage.dll > > > > 0x00007fff5e430000 - 0x00007fff5e614000 C:\Windows\SYSTEM32\DBGHELP.DLL > > > > 0x00007fff45170000 - 0x00007fff4519c000 C:\Windows\SYSTEM32\dbgcore.DLL > > > > 0x00007fff60d40000 - 0x00007fff60dc3000 C:\Windows\System32\bcryptPrimitives.dll > > > > 0x00007fff44f70000 - 0x00007fff44f95000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\java.dll > > > > 0x00007fff612c0000 - 0x00007fff619ff000 C:\Windows\System32\SHELL32.dll > > > > 0x00007fff5e620000 - 0x00007fff5edb0000 C:\Windows\SYSTEM32\windows.storage.dll > > > > 0x00007fff62650000 - 0x00007fff629a5000 C:\Windows\System32\combase.dll > > > > 0x00007fff60280000 - 0x00007fff602ae000 C:\Windows\SYSTEM32\Wldp.dll > > > > 0x00007fff61c40000 - 0x00007fff61ced000 C:\Windows\System32\SHCORE.dll > > > > 0x00007fff62f70000 - 0x00007fff62fc5000 C:\Windows\System32\shlwapi.dll > > > > 0x00007fff60770000 - 0x00007fff6078f000 C:\Windows\SYSTEM32\profapi.dll > > > > 0x00007fff44f10000 - 0x00007fff44f29000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\net.dll > > > > 0x00007fff5ada0000 - 0x00007fff5aeac000 C:\Windows\SYSTEM32\WINHTTP.dll > > > > 0x00007fff5ffe0000 - 0x00007fff6004a000 C:\Windows\system32\mswsock.dll > > > > 0x00007fff28650000 - 0x00007fff28665000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\nio.dll > > > > 0x00007ffeda3b0000 - 0x00007ffede7d1000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\libclang.dll > > > > 0x00007fff62ea0000 - 0x00007fff62f6d000 C:\Windows\System32\OLEAUT32.dll > > > > 0x00007fff61190000 - 0x00007fff612ba000 C:\Windows\System32\ole32.dll > > > > 0x00007fff5dac0000 - 0x00007fff5db5e000 C:\Windows\system32\uxtheme.dll > > > > 0x00007fff61e30000 - 0x00007fff61ed9000 C:\Windows\System32\clbcatq.dll > > > > 0x00007fff601d0000 - 0x00007fff601e8000 C:\Windows\SYSTEM32\CRYPTSP.dll > > > > 0x00007fff5f8c0000 - 0x00007fff5f8f4000 C:\Windows\system32\rsaenh.dll > > > > 0x00007fff60930000 - 0x00007fff60957000 C:\Windows\System32\bcrypt.dll > > > > 0x00007fff60730000 - 0x00007fff6075e000 C:\Windows\SYSTEM32\USERENV.dll > > > > 0x00007fff601f0000 - 0x00007fff601fc000 C:\Windows\SYSTEM32\CRYPTBASE.dll > > > > 0x00007fff5fc80000 - 0x00007fff5fcbb000 C:\Windows\SYSTEM32\IPHLPAPI.DLL > > > > 0x00007fff62550000 - 0x00007fff62558000 C:\Windows\System32\NSI.dll > > > > 0x00007fff55080000 - 0x00007fff55097000 C:\Windows\SYSTEM32\dhcpcsvc6.DLL > > > > 0x00007fff55060000 - 0x00007fff5507d000 C:\Windows\SYSTEM32\dhcpcsvc.DLL > > > > 0x00007fff5fcd0000 - 0x00007fff5fd9b000 C:\Windows\SYSTEM32\DNSAPI.dll > > > > dbghelp: loaded successfully - version: 4.0.5 - missing functions: none > > > > symbol engine: initialized successfully - sym options: 0x614 - pdb path: .;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin;C:\Windows\SYSTEM32;C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server > > > > VM Arguments: > > > > jvm_args: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract > > > > java_command: jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h > > > > java_class_path (initial): > > > > Launcher Type: SUN_STANDARD > > > > [Global flags] > > > > intx CICompilerCount = 4 {product} {ergonomic} > > > > uint ConcGCThreads = 2 {product} {ergonomic} > > > > uint G1ConcRefinementThreads = 8 {product} {ergonomic} > > > > size_t G1HeapRegionSize = 2097152 {product} {ergonomic} > > > > uintx GCDrainStackTargetSize = 64 {product} {ergonomic} > > > > size_t InitialHeapSize = 8388608 {product} {command line} > > > > size_t MarkStackSize = 4194304 {product} {ergonomic} > > > > size_t MaxHeapSize = 4223664128 {product} {ergonomic} > > > > size_t MaxNewSize = 2533359616 {product} {ergonomic} > > > > size_t MinHeapDeltaBytes = 2097152 {product} {ergonomic} > > > > size_t MinHeapSize = 8388608 {product} {command line} > > > > uintx NonNMethodCodeHeapSize = 5839372 {pd product} {ergonomic} > > > > uintx NonProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} > > > > uintx ProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} > > > > uintx ReservedCodeCacheSize = 251658240 {pd product} {ergonomic} > > > > bool SegmentedCodeCache = true {product} {ergonomic} > > > > size_t SoftMaxHeapSize = 4223664128 {manageable} {ergonomic} > > > > bool UseCompressedClassPointers = true {product lp64_product} {ergonomic} > > > > bool UseCompressedOops = true {product lp64_product} {ergonomic} > > > > bool UseG1GC = true {product} {ergonomic} > > > > bool UseLargePagesIndividualAllocation = false {pd product} {ergonomic} > > > > Logging: > > > > Log output configuration: > > > > #0: stdout all=warning uptime,level,tags > > > > #1: stderr all=off uptime,level,tags > > > > Environment Variables: > > > > JAVA_HOME=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 > > > > PATH=C:\Program Files\Zulu\zulu-11\bin\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Program Files (x86)\apache-ant-1.9.16\bin;C:\Program Files\CMake\bin;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\7-Zip;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\gawk-3.1.6-1-bin\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin;C:\Users\Martin\AppData\Local\Microsoft\WindowsApps;C:\Users\Martin\AppData\Local\atom\bin;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Users\Martin\.dotnet\tools > > > > USERNAME=Martin > > > > OS=Windows_NT > > > > PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 140 Stepping 1, GenuineIntel > > > > --------------- S Y S T E M --------------- > > > > OS: > > > > Windows 10 , 64 bit Build 19041 (10.0.19041.1348) > > > > OS uptime: 0 days 4:15 hours > > > > Hyper-V role detected > > > > CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 6 model 140 stepping 1 microcode 0x86, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, avx512f, avx512dq, avx512cd, avx512bw, avx512vl, sha, fma, vzeroupper, avx512_vpopcntdq, avx512_vpclmulqdq, avx512_vaes, avx512_vnni, clflush, clflushopt, clwb, avx512_vbmi2, avx512_vbmi, hv > > > > Memory: 4k page, system-wide physical 16107M (6064M free) > > > > TotalPageFile size 20971M (AvailPageFile size 8500M) > > > > current process WorkingSet (physical memory assigned to process): 136M, peak: 147M > > > > current process commit charge ("private bytes"): 177M, peak: 191M > > > > vm_info: OpenJDK 64-Bit Server VM (17-panama+3-167) for windows-amd64 JRE (17-panama+3-167), built on May 18 2021 13:10:19 by "mach5one" with MS VC++ 16.8 (VS2019) > > > > END. > > > > Sent with ProtonMail Secure Email. > > > > ??????? Original Message ??????? > > > > Le vendredi 12 novembre 2021 ? 15:47, Martin Pernollet martin.pernollet at protonmail.com a ?crit : > > > > > Thanks Jon, > > > > > > MinGW did not create a GL.dll file but rather libfreeglut.dll so I changed to > > > > > > public class glut_h extends glut_h_3 { > > > > > > static { > > > > > > System.loadLibrary("libfreeglut"); > > > > > > But it still fails, this time due to unresolved dependencies. Dependency Walker reveals tons of unreachable DLL (see screenshot). > > > > > > This failed attempt is documented here https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/issues/11;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI_ssFZQS$ > > > > > > I'll follow your suggestion and update documentation and notify you once I got it working. > > > > > > ??????? Original Message ??????? > > > > > > Le vendredi 12 novembre 2021 ? 15:17, Jorn Vernee jorn.vernee at oracle.com a ?crit : > > > > > > > Hi Martin, > > > > > > > > Thanks for testing this! > > > > > > > > The UnsatisfiedLinkError is not from code looking for a header file, > > > > > > > > it's from looking for a library/.dll file named GL.dll. On Windows > > > > > > > > though, freeglut needs the opengl libraries that come bundled with > > > > > > > > Windows (found in C:\Windows\System32), named opengl32 and glu32. The > > > > > > > > script should already add -l flags for those. > > > > > > > > WRT the jextract error you see. > > > > > > > > I have not tried to run the sample with freeglut installed through MingW > > > > > > > > yet. I instead used the freeglut package for MSVC here: > > > > > > > > https://urldefense.com/v3/https://www.transmissionzero.co.uk/software/freeglut-devel/;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI2nUkNV_$ extracted > > > > > > > > that in some folder, and the pointed freeglutPath at that folder. > > > > > > > > Note that jextract is using clang underneath to do the parsing. I know > > > > > > > > clang works pretty well with MSVC/Windows SDK header files, but I'm > > > > > > > > guessing it can not understand the MingW headers, looking at your error. > > > > > > > > I think it's having problems with __MINGW_NOTHROW and > > > > > > > > __MINGW_ATTRIB_NORETURN, which look like compiler builtins. > > > > > > > > I'd suggest trying the freeglut package I linked to instead, together > > > > > > > > with the Windows SDK headers (which clang should find automatically), > > > > > > > > and taking MingW headers out of the equation for now. We should probably > > > > > > > > create a README for that sample to include instructions on how to get > > > > > > > > freeglut. > > > > > > > > Note that on top of that, you will also have to change Teapot.java to > > > > > > > > account for a change in parameter names resulting in slightly different > > > > > > > > code being generated by jextract [1]. > > > > > > > > HTH, > > > > > > > > Jorn > > > > > > > > [1] : > > > > > > > > diff --git a/opengl/Teapot.java b/opengl/Teapot.java > > > > > > > > index 22d1f44..d5eb786 100644 > > > > > > > > --- a/opengl/Teapot.java > > > > > > > > +++ b/opengl/Teapot.java > > > > > > > > @@ -79,8 +79,8 @@ public class Teapot { > > > > > > > > glutInitWindowSize(500, 500); > > > > > > > > glutCreateWindow(allocator.allocateUtf8String("Hello Panama!")); > > > > > > > > var teapot = new Teapot(allocator); > > > > > > > > -??????????? var displayStub = > > > > > > > > glutDisplayFunc$func.allocate(teapot::display, scope); > > > > > > > > -??????????? var idleStub = glutIdleFunc$func.allocate(teapot::onIdle, > > > > > > > > scope); > > > > > > > > +??????????? var displayStub = > > > > > > > > glutDisplayFunc$callback.allocate(teapot::display, scope); > > > > > > > > +??????????? var idleStub = > > > > > > > > glutIdleFunc$callback.allocate(teapot::onIdle, scope); > > > > > > > > glutDisplayFunc(displayStub); > > > > > > > > glutIdleFunc(idleStub); > > > > > > > > glutMainLoop(); > > > > > > > > On 12/11/2021 13:01, Martin Pernollet wrote: > > > > > > > > > Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows : > > > > > > > > > > public class glut_h extends glut_h_3 { > > > > > > > > > > static { > > > > > > > > > > System.loadLibrary("GL"); > > > > > > > > > > System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT"); > > > > > > > > > > } > > > > > > > > > > while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW. > > > > > > > > > > Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir. > > > > > > > > > > So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception : > > > > > > > > > > PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1 > > > > > > > > > > [...] > > > > > > > > > > freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32 > > > > > > > > > > WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract > > > > > > > > > > C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator > > > > > > > > > > ERROR: jextract exited with non-zero exit code: 3 > > > > > > > > > > Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 : > > > > > > > > > > 358: #ifndef _CRT_TERMINATE_DEFINED > > > > > > > > > > 359: #define _CRT_TERMINATE_DEFINED > > > > > > > > > > 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; > > > > > > > > > > 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN; > > > > > > > > > > I should mention that > > > > > > > > > > - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct. > > > > > - I verified GCC and G++ are callable from Powershell > > > > > - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself. > > > > > > > > > > Is this stdlib error something some of you already faced? How did you fix? > > > > > > > > > > Thanks! > > > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > > > ??????? Original Message ??????? > > > > > > > > > > Le lundi 18 octobre 2021 ? 11:29, Rado Smogura mail at smogura.eu a ?crit : > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > Let me answer the last questions about JExtract and .h files for every > > > > > > > > > > > > platform. > > > > > > > > > > > > It may be needed to do separate bindings, unless you can prove > > > > > > > > > > > > otherwise. The specifications provides .h files and names, but may not > > > > > > > > > > > > be clear if, > > > > > > > > > > > > - given name is variable, or define > > > > > > > > > > > > - values set to const / variable > > > > > > > > > > > > - expr() is method or define > > > > > > > > > > > > There was one experiment with POSIX, where even so standard things like > > > > > > > > > > > > net may differ on values assigned to DEFINED between Linux & OSX. > > > > > > > > > > > > Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other, > > > > > > > > > > > > and this values will be "inlined" into extracted code. > > > > > > > > > > > > However how exactly is with OpenGL I don't know. > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > Rado > > > > > > > > > > > > On 17.10.2021 15:20, Martin Pernollet wrote: > > > > > > > > > > > > > > > > > > > Report about more intensive use of foreign function API > > > > > > > > > > > > > > I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn?t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow : > > > > > > > > > > > > > > void onIdle() { > > > > > > > > > > > > > > throw new IllegalArgumentException("Teapot does not support coffee"); > > > > > > > > > > > > > > } > > > > > > > > > > > > > > My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412. > > > > > > > > > > > > > > I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before. > > > > > > > > > > > > > > Integration in an AWT Canvas > > > > > > > > > > > > > > Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU. > > > > > > > > > > > > > > It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc. > > > > > > > > > > > > > > I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL. > > > > > > > > > > > > > > Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) > > > > > > > > > > > > > > I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way). > > > > > > > > > > > > > > More practical questions about JExtract > > > > > > > > > > > > > > I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case. > > > > > > > > > > > > > > Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM? > > > > > > > > > > > > > > Thanks for reading! > > > > > > > > > > > > > > Martin > > > > > > > > > > > > > > [0] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8bHkQ00p$ > > > > > > > > > > > > > > [1] https://urldefense.com/v3/https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8ROseeEa$ > > > > > > > > > > > > > > [2] https://urldefense.com/v3/https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8WkFrawU$ From martin.pernollet at protonmail.com Sun Nov 14 17:27:45 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Sun, 14 Nov 2021 17:27:45 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> References: <3e7f733c-6bd8-d8b2-4c45-6b352d95311c@oracle.com> <2c532257-b23b-6a24-3a6d-c841619eb97b@oracle.com> <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> Message-ID: Thank you John! My assumption about throwing JOGL & Java3D was that the complexity of the OpenGL world prevents to ensure the "Write it once, run it everywhere" at a reasonnable cost, hence was not worth pursuing. OpenGL has its own way of dealing with GPU versions and capabilities. Lot of opengl features rely on extensions and you do not really know in advance which extensions are available on your clients' computers. There is also GLSL which can also be versionned separately from OpenGL. Sven Gothel has done a great work in JOGL to improve this. Yet, it remains a bit of headache to have a consistent multiplatform experience in such an heterogeneous world! Anyway, good news if it rather a "mindset" change rather than a technological limitation :) Sent with [ProtonMail](https://protonmail.com/) Secure Email. ??????? Original Message ??????? Le dimanche 14 novembre 2021 ? 03:10, John Rose a ?crit : > On Oct 17, 2021, at 6:20 AM, Martin Pernollet wrote: > >> Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) > > I?m not an expert in AWT or graphics APIs but I do know a little about this history. First, 15-20 years is so long that you shouldn?t assume today?s conditions would be at all the same. > > Second, JOGL was built at a time when Sun had skunkworks projects investigating better native interoperation, similar in some ways to Panama, but Sun made a clear decision not to productize. At the time, JNI was seen by some as kind of defensive wall for Java. Now, not nearly so much. In fact, now Panama?s much more welcoming stance to native code is an important side to Java. Panama has been inspired, in part, by some of those old projects from 20 years ago. From samuel.audet at gmail.com Sun Nov 14 23:34:29 2021 From: samuel.audet at gmail.com (Samuel Audet) Date: Mon, 15 Nov 2021 08:34:29 +0900 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <3e7f733c-6bd8-d8b2-4c45-6b352d95311c@oracle.com> <2c532257-b23b-6a24-3a6d-c841619eb97b@oracle.com> <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> Message-ID: <909fdb15-0b93-b73f-41f8-ddef082a3ada@gmail.com> Hi, Martin, For what it's worth, OpenGL is considered legacy tech these days. I would suggest looking into Vulkan... Samuel On 11/15/21 02:27, Martin Pernollet wrote: > Thank you John! > > My assumption about throwing JOGL & Java3D was that the complexity of the OpenGL world prevents to ensure the "Write it once, run it everywhere" at a reasonnable cost, hence was not worth pursuing. > > OpenGL has its own way of dealing with GPU versions and capabilities. Lot of opengl features rely on extensions and you do not really know in advance which extensions are available on your clients' computers. There is also GLSL which can also be versionned separately from OpenGL. Sven Gothel has done a great work in JOGL to improve this. Yet, it remains a bit of headache to have a consistent multiplatform experience in such an heterogeneous world! > > Anyway, good news if it rather a "mindset" change rather than a technological limitation :) > > Sent with [ProtonMail](https://protonmail.com/) Secure Email. > > ??????? Original Message ??????? > Le dimanche 14 novembre 2021 ? 03:10, John Rose a ?crit : > >> On Oct 17, 2021, at 6:20 AM, Martin Pernollet wrote: >> >>> Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) >> >> I?m not an expert in AWT or graphics APIs but I do know a little about this history. First, 15-20 years is so long that you shouldn?t assume today?s conditions would be at all the same. >> >> Second, JOGL was built at a time when Sun had skunkworks projects investigating better native interoperation, similar in some ways to Panama, but Sun made a clear decision not to productize. At the time, JNI was seen by some as kind of defensive wall for Java. Now, not nearly so much. In fact, now Panama?s much more welcoming stance to native code is an important side to Java. Panama has been inspired, in part, by some of those old projects from 20 years ago. From duke at openjdk.java.net Mon Nov 15 01:39:19 2021 From: duke at openjdk.java.net (duke) Date: Mon, 15 Nov 2021 01:39:19 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <540fb52d-7100-4561-92e5-836505204f92@openjdk.org> Changeset: 4029dd5d Author: Nick Gasson Date: 2021-11-15 01:37:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4029dd5dacf73ca528d70ff2addda2dc027b093d 8276987: Optimized upcall stub should be printed with -XX:+PrintStubCode Reviewed-by: jvernee ! src/hotspot/share/code/codeBlob.cpp Changeset: cd2519a4 Author: duke Date: 2021-11-15 01:38:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd2519a49d93f01811805c695a4d64d67fe4691f Automatic merge of foreign-memaccess+abi into foreign-jextract From ngasson at openjdk.java.net Mon Nov 15 01:40:50 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 15 Nov 2021 01:40:50 GMT Subject: [foreign-memaccess+abi] Integrated: 8276987: Optimized upcall stub should be printed with -XX:+PrintStubCode In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 08:21:27 GMT, Nick Gasson wrote: > That would allow it to be found by JMH's profasm which uses `-XX:+PrintStubCode` to collect the addresses of stubs. Note that JMH at the moment can't actually parse the stubs printed by `trace_new_stub` (because they have a "Decoding ..." prefix and don't include the end address), but that can be fixed on the JMH side. This pull request has now been integrated. Changeset: 4029dd5d Author: Nick Gasson URL: https://git.openjdk.java.net/panama-foreign/commit/4029dd5dacf73ca528d70ff2addda2dc027b093d Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8276987: Optimized upcall stub should be printed with -XX:+PrintStubCode Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/611 From martin.pernollet at protonmail.com Mon Nov 15 07:33:56 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Mon, 15 Nov 2021 07:33:56 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <3e7f733c-6bd8-d8b2-4c45-6b352d95311c@oracle.com> <2c532257-b23b-6a24-3a6d-c841619eb97b@oracle.com> <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> Message-ID: <-QTuGDa0nmGTEPQ9e09MZxEU9ozr5M4FRwmJvR330RmH9yJsaRFWk0Iat-WWquO9MFmpmJst0bsK-JTJfjM2cDsdbVl4z9QjcRKqkUftG6U=@protonmail.com> Hi, I am now on Ubuntu. The original teapot sample is working (just required to change glutDisplayFunc$func to glutDisplayFunc$callback). I got an UnstasfiedLinkException with other programs. I wonder if you have a suggestion to help me understand my mistake? LDD command does not help. Like for the NPE, we lack a bit of info for debugging. --------------------------------------------------------------------------- Console says Uncaught exception: java.lang.UnsatisfiedLinkError {0x0000000091ac9b58} - klass: 'java/lang/UnsatisfiedLinkError' # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (universalUpcallHandler.cpp:113), pid=33668, tid=33677 # Error: ShouldNotReachHere() --------------------------------------------------------------------------- Core dump says (see attached the complete core dump file) Current thread (0x00007f5d580268c0): JavaThread "main" [_thread_in_Java, id=35593, stack(0x00007f5d5f59e000,0x00007f5d5f69f000)] Stack: [0x00007f5d5f59e000,0x00007f5d5f69f000], sp=0x00007f5d5f69c8b0, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xd993a3] ProgrammableUpcallHandler::handle_uncaught_exception(oopDesc*)+0x43 v ~BufferBlob::panama_upcall_stub C [libglut.so.3.9.0+0x20895] glutMainLoopEvent+0x2a5 Register to memory mapping: RAX=0x00007f5d60cc4000 points into unknown readable memory: 0x0000000000000058 | 58 00 00 00 00 00 00 00 RBX=0x00007f5d4184556a is at code_begin+842 in [CodeBlob (0x00007f5d41845190)] Framesize: 0 BufferBlob (0x00007f5d41845190) used for panama_upcall_stub RCX=0x000000000000000a is an unknown value RDX=0x0 is NULL RSP=0x00007f5d5f69c8b0 is pointing into the stack for thread: 0x00007f5d580268c0 RBP=0x00007f5d5f69c8c0 is pointing into the stack for thread: 0x00007f5d580268c0 RSI=0x0000000000000071 is an unknown value RDI=0x00007f5d606f6108: in /usr/lib/jvm/jdk-17-panama/lib/server/libjvm.so at 0x00007f5d5f7f9000 R8 =0x0 is NULL R9 =0x00007f5d5f69c8a0 is pointing into the stack for thread: 0x00007f5d580268c0 R10=0x0 is NULL R11=0x0 is NULL R12=0x0000000091d82828 is an oop: java.lang.UnsatisfiedLinkError {0x0000000091d82828} - klass: 'java/lang/UnsatisfiedLinkError' R13=0x00007f5d1c42fbdc is pointing into metadata R14=0x00007f5d5f69c8c8 is pointing into the stack for thread: 0x00007f5d580268c0 R15=0x00007f5d580268c0 is a thread --------------------------------------------------------------------------- I verified with LDD if the lib I am linking to has dependencies problem but it seams to be ok. ldd --verbose /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 linux-vdso.so.1 (0x00007ffc37dcd000) libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007effdf322000) libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007effdf1e5000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007effdf096000) libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007effdf084000) libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007effdf07d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007effdee8b000) libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007effdedd1000) libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007effded9d000) libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007effded73000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007effded6d000) /lib64/ld-linux-x86-64.so.2 (0x00007effdf608000) libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007effded58000) libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007effded50000) libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007effded48000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007effded2e000) Version information: /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0: libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6 libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libGL.so.1: libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libX11.so.6: libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.26) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libm.so.6: ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libXi.so.6: libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libXxf86vm.so.1: libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6: ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/libGLdispatch.so.0: libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libGLX.so.0: libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libxcb.so.1: libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libdl.so.2: ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libXext.so.6: libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libXau.so.6: libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libXdmcp.so.6: libbsd.so.0 (LIBBSD_0.2) => /lib/x86_64-linux-gnu/libbsd.so.0 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libbsd.so.0: libc.so.6 (GLIBC_2.25) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.16) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.8) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 From martin.pernollet at protonmail.com Mon Nov 15 07:36:59 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Mon, 15 Nov 2021 07:36:59 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: <909fdb15-0b93-b73f-41f8-ddef082a3ada@gmail.com> References: <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> <909fdb15-0b93-b73f-41f8-ddef082a3ada@gmail.com> Message-ID: Yes. This is something that could be done with JExtract I think. ??????? Original Message ??????? Le lundi 15 novembre 2021 ? 00:34, Samuel Audet a ?crit : > Hi, Martin, > > For what it's worth, OpenGL is considered legacy tech these days. I > > would suggest looking into Vulkan... > > Samuel > > On 11/15/21 02:27, Martin Pernollet wrote: > > > Thank you John! > > > > My assumption about throwing JOGL & Java3D was that the complexity of the OpenGL world prevents to ensure the "Write it once, run it everywhere" at a reasonnable cost, hence was not worth pursuing. > > > > OpenGL has its own way of dealing with GPU versions and capabilities. Lot of opengl features rely on extensions and you do not really know in advance which extensions are available on your clients' computers. There is also GLSL which can also be versionned separately from OpenGL. Sven Gothel has done a great work in JOGL to improve this. Yet, it remains a bit of headache to have a consistent multiplatform experience in such an heterogeneous world! > > > > Anyway, good news if it rather a "mindset" change rather than a technological limitation :) > > > > Sent with ProtonMail Secure Email. > > > > ??????? Original Message ??????? > > > > Le dimanche 14 novembre 2021 ? 03:10, John Rose john.r.rose at oracle.com a ?crit : > > > > > On Oct 17, 2021, at 6:20 AM, Martin Pernollet martin.pernollet at protonmail.com wrote: > > > > > > > Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) > > > > > > I?m not an expert in AWT or graphics APIs but I do know a little about this history. First, 15-20 years is so long that you shouldn?t assume today?s conditions would be at all the same. > > > > > > Second, JOGL was built at a time when Sun had skunkworks projects investigating better native interoperation, similar in some ways to Panama, but Sun made a clear decision not to productize. At the time, JNI was seen by some as kind of defensive wall for Java. Now, not nearly so much. In fact, now Panama?s much more welcoming stance to native code is an important side to Java. Panama has been inspired, in part, by some of those old projects from 20 years ago. From maurizio.cimadamore at oracle.com Mon Nov 15 10:43:46 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 15 Nov 2021 10:43:46 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: <-QTuGDa0nmGTEPQ9e09MZxEU9ozr5M4FRwmJvR330RmH9yJsaRFWk0Iat-WWquO9MFmpmJst0bsK-JTJfjM2cDsdbVl4z9QjcRKqkUftG6U=@protonmail.com> References: <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> <-QTuGDa0nmGTEPQ9e09MZxEU9ozr5M4FRwmJvR330RmH9yJsaRFWk0Iat-WWquO9MFmpmJst0bsK-JTJfjM2cDsdbVl4z9QjcRKqkUftG6U=@protonmail.com> Message-ID: Hi, from the top of my head, this looks like an exception thrown _while_ you are executing an upcall. And it also looks like you are missing some of the latest patches which will generate a "normal" stack trace. So you only see the exception name (UnsatisfiedLink). As a general rule, if an exception occurs when an upcall is executing, only option is to exit the Java program, so that we don't leave the native code in a potentially bad state. But more recent releases of the linker API do a better job at presenting this as an "exception" (although one that cannot be caught) rather than a blunt crash. If you can't update to a newer build, I'd look into all upcall code, looking for all pieces of code which might do System.load/loadLibrary. Maurizio On 15/11/2021 07:33, Martin Pernollet wrote: > Hi, > > I am now on Ubuntu. The original teapot sample is working (just > required to change glutDisplayFunc$func to glutDisplayFunc$callback). > > I got an UnstasfiedLinkException with other programs. I wonder if you > have a suggestion to help me understand my mistake? LDD command does > not help. Like for the NPE, we lack a bit of info for debugging. > > --------------------------------------------------------------------------- > Console says > > Uncaught exception: > java.lang.UnsatisfiedLinkError > {0x0000000091ac9b58} - klass: 'java/lang/UnsatisfiedLinkError' > # > # A fatal error has been detected by the Java Runtime Environment: > # > #? Internal Error (universalUpcallHandler.cpp:113), pid=33668, tid=33677 > #? Error: ShouldNotReachHere() > > --------------------------------------------------------------------------- > Core dump says (see attached the complete core dump file) > > Current thread (0x00007f5d580268c0):? JavaThread "main" > [_thread_in_Java, id=35593, stack(0x00007f5d5f59e000,0x00007f5d5f69f000)] > > Stack: [0x00007f5d5f59e000,0x00007f5d5f69f000], > sp=0x00007f5d5f69c8b0,? free space=1018k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V? [libjvm.so+0xd993a3] > ProgrammableUpcallHandler::handle_uncaught_exception(oopDesc*)+0x43 > v? ~BufferBlob::panama_upcall_stub > C? [libglut.so.3.9.0+0x20895]? glutMainLoopEvent+0x2a5 > > Register to memory mapping: > > RAX=0x00007f5d60cc4000 points into unknown readable memory: > 0x0000000000000058 | 58 00 00 00 00 00 00 00 > RBX=0x00007f5d4184556a is at code_begin+842 in > [CodeBlob (0x00007f5d41845190)] > Framesize: 0 > BufferBlob (0x00007f5d41845190) used for panama_upcall_stub > RCX=0x000000000000000a is an unknown value > RDX=0x0 is NULL > RSP=0x00007f5d5f69c8b0 is pointing into the stack for thread: > 0x00007f5d580268c0 > RBP=0x00007f5d5f69c8c0 is pointing into the stack for thread: > 0x00007f5d580268c0 > RSI=0x0000000000000071 is an unknown value > RDI=0x00007f5d606f6108: in > /usr/lib/jvm/jdk-17-panama/lib/server/libjvm.so at 0x00007f5d5f7f9000 > R8 =0x0 is NULL > R9 =0x00007f5d5f69c8a0 is pointing into the stack for thread: > 0x00007f5d580268c0 > R10=0x0 is NULL > R11=0x0 is NULL > R12=0x0000000091d82828 is an oop: java.lang.UnsatisfiedLinkError > {0x0000000091d82828} - klass: 'java/lang/UnsatisfiedLinkError' > R13=0x00007f5d1c42fbdc is pointing into metadata > R14=0x00007f5d5f69c8c8 is pointing into the stack for thread: > 0x00007f5d580268c0 > R15=0x00007f5d580268c0 is a thread > > --------------------------------------------------------------------------- > I verified with LDD if the lib I am linking to has dependencies > problem but it seams to be ok. > > ldd --verbose /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 > linux-vdso.so.1 (0x00007ffc37dcd000) > libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007effdf322000) > libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007effdf1e5000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007effdf096000) > libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007effdf084000) > libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 > (0x00007effdf07d000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007effdee8b000) > libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 > (0x00007effdedd1000) > libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007effded9d000) > libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007effded73000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007effded6d000) > /lib64/ld-linux-x86-64.so.2 (0x00007effdf608000) > libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007effded58000) > libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007effded50000) > libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007effded48000) > libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007effded2e000) > > Version information: > /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0: > libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6 > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libGL.so.1: > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libX11.so.6: > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.26) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libm.so.6: > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libXi.so.6: > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libXxf86vm.so.1: > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libc.so.6: > ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > /lib/x86_64-linux-gnu/libGLdispatch.so.0: > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libGLX.so.0: > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libxcb.so.1: > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libdl.so.2: > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libXext.so.6: > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libXau.so.6: > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libXdmcp.so.6: > libbsd.so.0 (LIBBSD_0.2) => /lib/x86_64-linux-gnu/libbsd.so.0 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > /lib/x86_64-linux-gnu/libbsd.so.0: > libc.so.6 (GLIBC_2.25) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.16) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.8) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 > From jorn.vernee at oracle.com Mon Nov 15 12:33:14 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Mon, 15 Nov 2021 13:33:14 +0100 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> Message-ID: <52fc2136-2030-e8e1-1824-0bcb63c849cb@oracle.com> Hi Martin, The size is used for a code buffer into which we generate machine code at runtime. Different machines result in different code, different code sizes, and different alignment constraints (which can also affect code size). Even different GCs can affect code size differently. This is the reason it worked fine most of the time when testing, but failed on some configurations. In this case someone else found the error first through testing and fixed it. I don't see a need to have a flag for this (note that we have no such flag for any other code buffer sizes). The size of the buffer is a VM implementation detail. We only have to get it right once. It's not really something that is application dependent. Jorn On 14/11/2021 18:17, Martin Pernollet wrote: > Hi Jorn, > > I mainly understand from the fix that there was a memory size limit reached on my machine but not on yours when generating bindings. > > Do you think doubling this memory is a long term fix? Wouldn't it be better to be able to override the memory limit from an option, a bit like -Xmx.. ? > > > > ??????? Original Message ??????? > > Le vendredi 12 novembre 2021 ? 16:25, Jorn Vernee a ?crit : > >> Hi Martin, >> >> This looks like a case of: https://urldefense.com/v3/__https://github.com/openjdk/jdk17/pull/35__;!!ACWV5N9M2RV99hQ!b-P5fmrs2wj_aH1VLp0eneUqW9DNk2MyGppci8h6WiBsKunK3C2nCPFZrPcwSs3f$ >> >> Are you using the panama snapshot from jdk.java.net? That snapshot >> >> doesn't contain the fix AFAIK. The samples are also made for the latest >> >> panama-foreign API, so they won't work with the snapshot (at least not >> >> out of the box). >> >> I think the only solution to the crash is to build the >> >> panama-foreign/foreign-jextract branch yourself. >> >> Sorry, >> >> Jorn >> >> On 12/11/2021 16:09, Martin Pernollet wrote: >> >>> When I now try with the precompiled freeglut you suggest I got a jextract crash. My exact command was >>> >>> C:\Program" "Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe `-I "C:\\Users\\Martin\\Dev\\jzy3d\\external\\freeglut\\include"` >>> >>> "-l" opengl32 `"-l" glu32` >>> >>> "-l" freeglut `"-t" "opengl"` >>> >>> "--" ` >>> >>> "C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h" >>> >>> And the core dump file says >>> >>> A fatal error has been detected by the Java Runtime Environment: >>> ================================================================ >>> >>> Internal Error (codeBuffer.cpp:972), pid=8664, tid=17112 >>> ======================================================== >>> >>> guarantee(sect->end() <= tend) failed: sanity >>> ============================================= >>> >>> JRE version: OpenJDK Runtime Environment (17.0+3) (build 17-panama+3-167) >>> ========================================================================= >>> >>> Java VM: OpenJDK 64-Bit Server VM (17-panama+3-167, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) >>> ============================================================================================================================================== >>> >>> No core dump will be written. Minidumps are not enabled by default on client versions of Windows >>> ================================================================================================ >>> >>> If you would like to submit a bug report, please visit: >>> ======================================================= >>> >>> https://urldefense.com/v3/https://bugreport.java.com/bugreport/crash.jsp;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI5KK9Rju$ >>> ============================================================================================================================================================ >>> >>> --------------- S U M M A R Y ------------ >>> >>> Command Line: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h >>> >>> Host: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 8 cores, 15G, Windows 10 , 64 bit Build 19041 (10.0.19041.1348) >>> >>> Time: Fri Nov 12 16:06:50 2021 Europe de l , 64 bit Build 19041 (10.0.19041.1348) elapsed time: 0.603555 seconds (0d 0h 0m 0s) >>> >>> --------------- T H R E A D --------------- >>> >>> Current thread (0x000001beaa55be10): JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] >>> >>> Stack: [0x0000003933800000,0x0000003933900000] >>> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>> >>> V [jvm.dll+0x668f4a] >>> >>> V [jvm.dll+0x7c69a9] >>> >>> V [jvm.dll+0x7c814e] >>> >>> V [jvm.dll+0x7c8757] >>> >>> V [jvm.dll+0x23ec9c] >>> >>> V [jvm.dll+0x1f92d0] >>> >>> V [jvm.dll+0x795431] >>> >>> V [jvm.dll+0x792fa9] >>> >>> C 0x000001beb1dfd661 >>> >>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >>> >>> j jdk.internal.foreign.abi.ProgrammableUpcallHandler.allocateOptimizedUpcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/ABIDescriptor;Ljdk/internal/foreign/abi/ProgrammableUpcallHandler$CallRegs;)J+0 jdk.incubator.foreign at 17-panama >>> >>> j jdk.internal.foreign.abi.ProgrammableUpcallHandler.make(Ljdk/internal/foreign/abi/ABIDescriptor;Ljava/lang/invoke/MethodHandle;Ljdk/internal/foreign/abi/CallingSequence;)Ljdk/internal/foreign/abi/UpcallHandler;+380 jdk.incubator.foreign at 17-panama >>> >>> j jdk.internal.foreign.abi.x64.windows.CallArranger.arrangeUpcall(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;Ljdk/incubator/foreign/FunctionDescriptor;)Ljdk/internal/foreign/abi/UpcallHandler;+28 jdk.incubator.foreign at 17-panama >>> >>> j jdk.internal.foreign.abi.x64.windows.Windowsx64Linker.upcallStub(Ljava/lang/invoke/MethodHandle;Ljdk/incubator/foreign/FunctionDescriptor;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+35 jdk.incubator.foreign at 17-panama >>> >>> j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;Ljdk/incubator/foreign/ResourceScope;)Ljdk/incubator/foreign/MemoryAddress;+34 jdk.incubator.jextract at 17-panama >>> >>> j jdk.internal.clang.libclang.RuntimeHelper.upcallStub(Ljava/lang/Class;Ljava/lang/Object;Ljdk/incubator/foreign/FunctionDescriptor;Ljava/lang/String;)Ljdk/incubator/foreign/MemoryAddress;+7 jdk.incubator.jextract at 17-panama >>> >>> j jdk.internal.clang.libclang.CXCursorVisitor.allocate(Ljdk/internal/clang/libclang/CXCursorVisitor;)Ljdk/incubator/foreign/MemoryAddress;+8 jdk.incubator.jextract at 17-panama >>> >>> j jdk.internal.clang.Cursor$CursorChildren.()V+15 jdk.incubator.jextract at 17-panama >>> >>> v ~StubRoutines::call_stub >>> >>> j jdk.internal.clang.Cursor.children()Ljava/util/stream/Stream;+1 jdk.incubator.jextract at 17-panama >>> >>> j jdk.internal.jextract.impl.Parser.parse(Ljava/nio/file/Path;Ljava/util/Collection;)Ljdk/incubator/jextract/Declaration$Scoped;+66 jdk.incubator.jextract at 17-panama >>> >>> j jdk.incubator.jextract.JextractTool.parse(Ljava/util/List;[Ljava/lang/String;)Ljdk/incubator/jextract/Declaration$Scoped;+55 jdk.incubator.jextract at 17-panama >>> >>> j jdk.incubator.jextract.JextractTool.run([Ljava/lang/String;)I+904 jdk.incubator.jextract at 17-panama >>> >>> j jdk.incubator.jextract.JextractTool.main([Ljava/lang/String;)V+46 jdk.incubator.jextract at 17-panama >>> >>> v ~StubRoutines::call_stub >>> >>> --------------- P R O C E S S --------------- >>> >>> Threads class SMR info: >>> >>> _java_thread_list=0x000001bece7196e0, length=13, elements={ >>> >>> 0x000001beaa55be10, 0x000001becd023240, 0x000001becd023e00, 0x000001becd0394b0, >>> >>> 0x000001becd03a070, 0x000001becd03ea50, 0x000001becd03f410, 0x000001becd0401b0, >>> >>> 0x000001becd041400, 0x000001becd042e10, 0x000001becdc945a0, 0x000001becdcab950, >>> >>> 0x000001becdf7e080 >>> >>> } >>> >>> Java Threads: ( => current thread ) >>> >>> =>0x000001beaa55be10 JavaThread "main" [_thread_in_vm, id=17112, stack(0x0000003933800000,0x0000003933900000)] >>> >>> 0x000001becd023240 JavaThread "Reference Handler" daemon [_thread_blocked, id=16356, stack(0x0000003933f00000,0x0000003934000000)] >>> >>> 0x000001becd023e00 JavaThread "Finalizer" daemon [_thread_blocked, id=6204, stack(0x0000003934000000,0x0000003934100000)] >>> >>> 0x000001becd0394b0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=972, stack(0x0000003934100000,0x0000003934200000)] >>> >>> 0x000001becd03a070 JavaThread "Attach Listener" daemon [_thread_blocked, id=2084, stack(0x0000003934200000,0x0000003934300000)] >>> >>> 0x000001becd03ea50 JavaThread "Service Thread" daemon [_thread_blocked, id=18128, stack(0x0000003934300000,0x0000003934400000)] >>> >>> 0x000001becd03f410 JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=3404, stack(0x0000003934400000,0x0000003934500000)] >>> >>> 0x000001becd0401b0 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=10160, stack(0x0000003934500000,0x0000003934600000)] >>> >>> 0x000001becd041400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=15728, stack(0x0000003934600000,0x0000003934700000)] >>> >>> 0x000001becd042e10 JavaThread "Sweeper thread" daemon [_thread_blocked, id=3932, stack(0x0000003934700000,0x0000003934800000)] >>> >>> 0x000001becdc945a0 JavaThread "Notification Thread" daemon [_thread_blocked, id=12368, stack(0x0000003934800000,0x0000003934900000)] >>> >>> 0x000001becdcab950 JavaThread "Common-Cleaner" daemon [_thread_blocked, id=15996, stack(0x0000003934a00000,0x0000003934b00000)] >>> >>> 0x000001becdf7e080 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=8236, stack(0x0000003934e00000,0x0000003934f00000)] >>> >>> Other Threads: >>> >>> 0x000001becd01c730 VMThread "VM Thread" [stack: 0x0000003933e00000,0x0000003933f00000] [id=8136] >>> >>> 0x000001becd00d9b0 WatcherThread [stack: 0x0000003934900000,0x0000003934a00000] [id=11228] >>> >>> 0x000001beaa5a9a40 GCTaskThread "GC Thread#0" [stack: 0x0000003933900000,0x0000003933a00000] [id=15472] >>> >>> 0x000001becde6f060 GCTaskThread "GC Thread#1" [stack: 0x0000003934b00000,0x0000003934c00000] [id=9408] >>> >>> 0x000001becde782a0 GCTaskThread "GC Thread#2" [stack: 0x0000003934c00000,0x0000003934d00000] [id=15952] >>> >>> 0x000001becde78560 GCTaskThread "GC Thread#3" [stack: 0x0000003934d00000,0x0000003934e00000] [id=17212] >>> >>> 0x000001bece9140e0 GCTaskThread "GC Thread#4" [stack: 0x0000003934f00000,0x0000003935000000] [id=13940] >>> >>> 0x000001bece914ea0 GCTaskThread "GC Thread#5" [stack: 0x0000003935000000,0x0000003935100000] [id=12744] >>> >>> 0x000001beaa5ba550 ConcurrentGCThread "G1 Main Marker" [stack: 0x0000003933a00000,0x0000003933b00000] [id=9236] >>> >>> 0x000001beaa5bbf70 ConcurrentGCThread "G1 Conc#0" [stack: 0x0000003933b00000,0x0000003933c00000] [id=17776] >>> >>> 0x000001beaa5e6a80 ConcurrentGCThread "G1 Refine#0" [stack: 0x0000003933c00000,0x0000003933d00000] [id=1088] >>> >>> 0x000001beaa5e84c0 ConcurrentGCThread "G1 Service" [stack: 0x0000003933d00000,0x0000003933e00000] [id=3248] >>> >>> Threads with active compile tasks: >>> >>> C2 CompilerThread0 608 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) >>> >>> VM state: not at safepoint (normal execution) >>> >>> VM Mutex/Monitor currently owned by a thread: None >>> >>> Heap address: 0x0000000704400000, size: 4028 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 >>> >>> CDS archive(s) mapped at: [0x0000000800000000-0x0000000800bb0000-0x0000000800bb0000), size 12255232, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. >>> >>> Compressed class space mapped at: 0x0000000800c00000-0x0000000840c00000, reserved size: 1073741824 >>> >>> Narrow klass base: 0x0000000800000000, Narrow klass shift: 3, Narrow klass range: 0x100000000 >>> >>> GC Precious Log: >>> >>> CPUs: 8 total, 8 available >>> >>> Memory: 16107M >>> >>> Large Page Support: Disabled >>> >>> NUMA Support: Disabled >>> >>> Compressed Oops: Enabled (Zero based) >>> >>> Heap Region Size: 2M >>> >>> Heap Min Capacity: 8M >>> >>> Heap Initial Capacity: 8M >>> >>> Heap Max Capacity: 4028M >>> >>> Pre-touch: Disabled >>> >>> Parallel Workers: 8 >>> >>> Concurrent Workers: 2 >>> >>> Concurrent Refinement Workers: 8 >>> >>> Periodic GC: Disabled >>> >>> Heap: >>> >>> garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 2 young (4096K), 1 survivors (2048K) >>> >>> Metaspace used 4346K, committed 5056K, reserved 1056768K >>> >>> class space used 589K, committed 896K, reserved 1048576K >>> >>> Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts), HC=humongous(continues), CS=collection set, F=free, OA=open archive, CA=closed archive, TAMS=top-at-mark-start (previous, next) >>> >>> | 0|0x0000000704400000, 0x00000007044e4e00, 0x0000000704600000| 44%| O| |TAMS 0x0000000704400000, 0x0000000704400000| Untracked >>> >>> | 1|0x0000000704600000, 0x0000000704600000, 0x0000000704800000| 0%| F| |TAMS 0x0000000704600000, 0x0000000704600000| Untracked >>> >>> | 2|0x0000000704800000, 0x00000007048fb810, 0x0000000704a00000| 49%| S|CS|TAMS 0x0000000704800000, 0x0000000704800000| Complete >>> >>> | 3|0x0000000704a00000, 0x0000000704bfa230, 0x0000000704c00000| 98%| E| |TAMS 0x0000000704a00000, 0x0000000704a00000| Complete >>> >>> Card table byte_map: [0x000001bec1900000,0x000001bec20e0000] _byte_map_base: 0x000001bebe0de000 >>> >>> Marking Bits (Prev, Next): (CMBitMap*) 0x000001beaa5aa060, (CMBitMap*) 0x000001beaa5aa0a0 >>> >>> Prev Bits: [0x000001bec28c0000, 0x000001bec67b0000) >>> >>> Next Bits: [0x000001bec67b0000, 0x000001beca6a0000) >>> >>> Polling page: 0x000001bea8380000 >>> >>> Metaspace: >>> >>> Usage: >>> >>> Non-class: 3.67 MB used. >>> >>> Class: 589.17 KB used. >>> >>> Both: 4.24 MB used. >>> >>> Virtual space: >>> >>> Non-class space: 8.00 MB reserved, 4.06 MB ( 51%) committed, 1 nodes. >>> >>> Class space: 1.00 GB reserved, 896.00 KB ( <1%) committed, 1 nodes. >>> >>> Both: 1.01 GB reserved, 4.94 MB ( <1%) committed. >>> >>> Chunk freelists: >>> >>> Non-Class: 2.55 MB >>> >>> Class: 2.96 MB >>> >>> Both: 5.51 MB >>> >>> MaxMetaspaceSize: unlimited >>> >>> CompressedClassSpaceSize: 1.00 GB >>> >>> Initial GC threshold: 21.00 MB >>> >>> Current GC threshold: 21.00 MB >>> >>> CDS: on >>> >>> MetaspaceReclaimPolicy: balanced >>> >>> - commit_granule_bytes: 65536. >>> - commit_granule_words: 8192. >>> - virtual_space_node_default_size: 1048576. >>> - enlarge_chunks_in_place: 1. >>> - new_chunks_are_fully_committed: 0. >>> - uncommit_free_chunks: 1. >>> - use_allocation_guard: 0. >>> - handle_deallocations: 1. >>> >>> Internal statistics: >>> >>> num_allocs_failed_limit: 0. >>> >>> num_arena_births: 990. >>> >>> num_arena_deaths: 0. >>> >>> num_vsnodes_births: 2. >>> >>> num_vsnodes_deaths: 0. >>> >>> num_space_committed: 79. >>> >>> num_space_uncommitted: 0. >>> >>> num_chunks_returned_to_freelist: 0. >>> >>> num_chunks_taken_from_freelist: 1166. >>> >>> num_chunk_merges: 0. >>> >>> num_chunk_splits: 758. >>> >>> num_chunks_enlarged: 370. >>> >>> num_purges: 0. >>> >>> CodeHeap 'non-profiled nmethods': size=120000Kb used=542Kb max_used=542Kb free=119458Kb >>> >>> bounds [0x000001beb98c0000, 0x000001beb9b30000, 0x000001bec0df0000] >>> >>> CodeHeap 'profiled nmethods': size=120000Kb used=1537Kb max_used=1537Kb free=118462Kb >>> >>> bounds [0x000001beb2390000, 0x000001beb2600000, 0x000001beb98c0000] >>> >>> CodeHeap 'non-nmethods': size=5760Kb used=1214Kb max_used=1246Kb free=4545Kb >>> >>> bounds [0x000001beb1df0000, 0x000001beb2060000, 0x000001beb2390000] >>> >>> total_blobs=1537 nmethods=1035 adapters=412 >>> >>> compilation: enabled >>> >>> stopped_count=0, restarted_count=0 >>> >>> full_count=0 >>> >>> Compilation events (20 events): >>> >>> Event: 0.590 Thread 0x000001becd041400 1020 3 java.lang.invoke.DirectMethodHandle:: (148 bytes) >>> >>> Event: 0.591 Thread 0x000001becd0401b0 nmethod 1019 0x000001beb9945710 code [0x000001beb9945880, 0x000001beb9945958] >>> >>> Event: 0.591 Thread 0x000001becd041400 nmethod 1020 0x000001beb2508510 code [0x000001beb25087c0, 0x000001beb2509748] >>> >>> Event: 0.591 Thread 0x000001becd0401b0 1021 4 jdk.internal.org.objectweb.asm.Frame::getLocal (46 bytes) >>> >>> Event: 0.591 Thread 0x000001becd0401b0 nmethod 1021 0x000001beb9946010 code [0x000001beb9946180, 0x000001beb9946258] >>> >>> Event: 0.592 Thread 0x000001becd041400 1024 3 java.lang.invoke.LambdaFormEditor$TransformKey::of (51 bytes) >>> >>> Event: 0.593 Thread 0x000001becd041400 nmethod 1024 0x000001beb2509c90 code [0x000001beb2509e80, 0x000001beb250a448] >>> >>> Event: 0.593 Thread 0x000001becd041400 1025 3 java.lang.invoke.LambdaFormEditor$TransformKey::packedBytes (39 bytes) >>> >>> Event: 0.593 Thread 0x000001becd041400 nmethod 1025 0x000001beb250a610 code [0x000001beb250a7a0, 0x000001beb250a8b8] >>> >>> Event: 0.593 Thread 0x000001becdf7e080 1028 4 java.lang.invoke.LambdaForm$BasicType::basicType (19 bytes) >>> >>> Event: 0.593 Thread 0x000001becd0401b0 1029 4 jdk.internal.org.objectweb.asm.Frame::pop (42 bytes) >>> >>> Event: 0.593 Thread 0x000001becd041400 1031 3 java.lang.invoke.MethodHandles::collectArguments (47 bytes) >>> >>> Event: 0.593 Thread 0x000001becd0401b0 nmethod 1029 0x000001beb9946910 code [0x000001beb9946a80, 0x000001beb9946b58] >>> >>> Event: 0.593 Thread 0x000001becd0401b0 1030 4 jdk.internal.org.objectweb.asm.Frame::merge (317 bytes) >>> >>> Event: 0.593 Thread 0x000001becd041400 nmethod 1031 0x000001beb250a990 code [0x000001beb250abc0, 0x000001beb250b3e8] >>> >>> Event: 0.593 Thread 0x000001becd041400 1032 3 java.lang.invoke.MethodHandles::collectArgumentsChecks (124 bytes) >>> >>> Event: 0.594 Thread 0x000001becd0401b0 nmethod 1030 0x000001beb9946c10 code [0x000001beb9946d80, 0x000001beb9946e78] >>> >>> Event: 0.594 Thread 0x000001becd0401b0 1034 4 java.lang.invoke.InvokerBytecodeGenerator::emitImplicitConversion (161 bytes) >>> >>> Event: 0.594 Thread 0x000001becd041400 nmethod 1032 0x000001beb250b790 code [0x000001beb250bb00, 0x000001beb250d2b8] >>> >>> Event: 0.594 Thread 0x000001becd041400 1033 3 java.lang.invoke.LambdaFormEditor::collectArgumentsForm (169 bytes) >>> >>> GC Heap History (10 events): >>> >>> Event: 0.086 GC heap before >>> >>> {Heap before GC invocations=0 (full 0): >>> >>> garbage-first heap total 8192K, used 2048K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 0 survivors (0K) >>> >>> Metaspace used 1471K, committed 1664K, reserved 1056768K >>> >>> class space used 151K, committed 256K, reserved 1048576K >>> >>> } >>> >>> Event: 0.088 GC heap after >>> >>> {Heap after GC invocations=1 (full 0): >>> >>> garbage-first heap total 8192K, used 1168K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 1 survivors (2048K) >>> >>> Metaspace used 1471K, committed 1664K, reserved 1056768K >>> >>> class space used 151K, committed 256K, reserved 1048576K >>> >>> } >>> >>> Event: 0.135 GC heap before >>> >>> {Heap before GC invocations=1 (full 0): >>> >>> garbage-first heap total 8192K, used 3216K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 2 young (4096K), 1 survivors (2048K) >>> >>> Metaspace used 2586K, committed 2880K, reserved 1056768K >>> >>> class space used 297K, committed 448K, reserved 1048576K >>> >>> } >>> >>> Event: 0.137 GC heap after >>> >>> {Heap after GC invocations=2 (full 0): >>> >>> garbage-first heap total 8192K, used 1270K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 1 survivors (2048K) >>> >>> Metaspace used 2586K, committed 2880K, reserved 1056768K >>> >>> class space used 297K, committed 448K, reserved 1048576K >>> >>> } >>> >>> Event: 0.165 GC heap before >>> >>> {Heap before GC invocations=2 (full 0): >>> >>> garbage-first heap total 8192K, used 3318K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 2 young (4096K), 1 survivors (2048K) >>> >>> Metaspace used 2912K, committed 3328K, reserved 1056768K >>> >>> class space used 360K, committed 576K, reserved 1048576K >>> >>> } >>> >>> Event: 0.167 GC heap after >>> >>> {Heap after GC invocations=3 (full 0): >>> >>> garbage-first heap total 8192K, used 1460K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 1 survivors (2048K) >>> >>> Metaspace used 2912K, committed 3328K, reserved 1056768K >>> >>> class space used 360K, committed 576K, reserved 1048576K >>> >>> } >>> >>> Event: 0.366 GC heap before >>> >>> {Heap before GC invocations=3 (full 0): >>> >>> garbage-first heap total 8192K, used 3508K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 2 young (4096K), 1 survivors (2048K) >>> >>> Metaspace used 3240K, committed 3712K, reserved 1056768K >>> >>> class space used 418K, committed 640K, reserved 1048576K >>> >>> } >>> >>> Event: 0.368 GC heap after >>> >>> {Heap after GC invocations=4 (full 0): >>> >>> garbage-first heap total 8192K, used 1629K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 1 survivors (2048K) >>> >>> Metaspace used 3240K, committed 3712K, reserved 1056768K >>> >>> class space used 418K, committed 640K, reserved 1048576K >>> >>> } >>> >>> Event: 0.570 GC heap before >>> >>> {Heap before GC invocations=4 (full 0): >>> >>> garbage-first heap total 8192K, used 3677K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 2 young (4096K), 1 survivors (2048K) >>> >>> Metaspace used 4023K, committed 4608K, reserved 1056768K >>> >>> class space used 525K, committed 832K, reserved 1048576K >>> >>> } >>> >>> Event: 0.572 GC heap after >>> >>> {Heap after GC invocations=5 (full 0): >>> >>> garbage-first heap total 8192K, used 1921K [0x0000000704400000, 0x0000000800000000) >>> >>> region size 2048K, 1 young (2048K), 1 survivors (2048K) >>> >>> Metaspace used 4023K, committed 4608K, reserved 1056768K >>> >>> class space used 525K, committed 832K, reserved 1048576K >>> >>> } >>> >>> Deoptimization events (14 events): >>> >>> Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb98c3cac relative=0x000000000000020c >>> >>> Event: 0.034 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb98c3cac method=java.lang.String.hashCode()I @ 42 c2 >>> >>> Event: 0.034 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb98c3cac sp=0x00000039338fe520 >>> >>> Event: 0.034 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe4b8 mode 2 >>> >>> Event: 0.122 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb23ab367 sp=0x00000039338fd790 >>> >>> Event: 0.122 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e46763 sp=0x00000039338fcbb0 mode 0 >>> >>> Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffff45 fr.pc=0x000001beb990a7e0 relative=0x0000000000007740 >>> >>> Event: 0.584 Thread 0x000001beaa55be10 Uncommon trap: reason=unstable_if action=reinterpret pc=0x000001beb990a7e0 method=jdk.internal.org.objectweb.asm.Frame.execute(IILjdk/internal/org/objectweb/asm/Symbol;Ljdk/internal/org/objectweb/asm/SymbolTable;)V @ 1 c2 >>> >>> Event: 0.584 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb990a7e0 sp=0x00000039338fcef0 >>> >>> Event: 0.584 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fcea8 mode 2 >>> >>> Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: trap_request=0xffffffcc fr.pc=0x000001beb9943df4 relative=0x0000000000000354 >>> >>> Event: 0.592 Thread 0x000001beaa55be10 Uncommon trap: reason=intrinsic_or_type_checked_inlining action=make_not_entrant pc=0x000001beb9943df4 method=java.util.Arrays.copyOf([Ljava/lang/Object;ILjava/lang/Class;)[Ljava/lang/Object; @ 35 c2 >>> >>> Event: 0.592 Thread 0x000001beaa55be10 DEOPT PACKING pc=0x000001beb9943df4 sp=0x00000039338fe2b0 >>> >>> Event: 0.592 Thread 0x000001beaa55be10 DEOPT UNPACKING pc=0x000001beb1e45c23 sp=0x00000039338fe258 mode 2 >>> >>> Classes unloaded (0 events): >>> >>> No events >>> >>> Classes redefined (0 events): >>> >>> No events >>> >>> Internal exceptions (20 events): >>> >>> Event: 0.424 Thread 0x000001beaa55be10 Exception (0x0000000704b67fa8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.566 Thread 0x000001beaa55be10 Exception (0x0000000704ba0908) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.572 Thread 0x000001beaa55be10 Exception (0x0000000704a048c8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.574 Thread 0x000001beaa55be10 Exception (0x0000000704a359b8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.576 Thread 0x000001beaa55be10 Exception (0x0000000704a69260) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.578 Thread 0x000001beaa55be10 Exception (0x0000000704a85548) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.579 Thread 0x000001beaa55be10 Exception (0x0000000704a9b548) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.581 Thread 0x000001beaa55be10 Exception (0x0000000704ac7840) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.582 Thread 0x000001beaa55be10 Exception (0x0000000704acada8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b0f9a8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.585 Thread 0x000001beaa55be10 Exception (0x0000000704b13248) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.588 Thread 0x000001beaa55be10 Exception (0x0000000704b66608) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b69ec0) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b72a48) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.589 Thread 0x000001beaa55be10 Exception (0x0000000704b765d8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7a480) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.590 Thread 0x000001beaa55be10 Exception (0x0000000704b7e200) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b99bd0) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.591 Thread 0x000001beaa55be10 Exception (0x0000000704b9d880) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Event: 0.593 Thread 0x000001beaa55be10 Exception (0x0000000704bd0ae8) >>> >>> thrown [t:\workspace\open\src\hotspot\share\interpreter\linkResolver.cpp, line 766] >>> >>> Events (20 events): >>> >>> Event: 0.423 loading class java/io/DeleteOnExitHook done >>> >>> Event: 0.423 loading class java/io/DeleteOnExitHook$1 >>> >>> Event: 0.424 loading class java/io/DeleteOnExitHook$1 done >>> >>> Event: 0.550 Thread 0x000001beceebb670 Thread exited: 0x000001beceebb670 >>> >>> Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef >>> >>> Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator >>> >>> Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator done >>> >>> Event: 0.551 loading class java/util/stream/Streams$ConcatSpliterator$OfRef done >>> >>> Event: 0.551 loading class java/util/stream/Streams$2 >>> >>> Event: 0.551 loading class java/util/stream/Streams$2 done >>> >>> Event: 0.570 Executing VM operation: G1CollectForAllocation >>> >>> Event: 0.572 Executing VM operation: G1CollectForAllocation done >>> >>> Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator >>> >>> Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator >>> >>> Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator done >>> >>> Event: 0.581 loading class jdk/internal/foreign/ArenaAllocator$BoundedArenaAllocator done >>> >>> Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler >>> >>> Event: 0.589 loading class jdk/internal/foreign/abi/ProgrammableUpcallHandler done >>> >>> Event: 0.594 loading class java/lang/invoke/MethodHandle$1 >>> >>> Event: 0.594 loading class java/lang/invoke/MethodHandle$1 done >>> >>> Dynamic libraries: >>> >>> 0x00007ff670d20000 - 0x00007ff670d28000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jextract.exe >>> >>> 0x00007fff63110000 - 0x00007fff63305000 C:\Windows\SYSTEM32\ntdll.dll >>> >>> 0x00007fff61a00000 - 0x00007fff61abe000 C:\Windows\System32\KERNEL32.DLL >>> >>> 0x00007fff60960000 - 0x00007fff60c28000 C:\Windows\System32\KERNELBASE.dll >>> >>> 0x00007fff60830000 - 0x00007fff60930000 C:\Windows\System32\ucrtbase.dll >>> >>> 0x00007fff567c0000 - 0x00007fff567d8000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jli.dll >>> >>> 0x00007fff57310000 - 0x00007fff5732a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\VCRUNTIME140.dll >>> >>> 0x00007fff629b0000 - 0x00007fff62b51000 C:\Windows\System32\USER32.dll >>> >>> 0x00007fff60f30000 - 0x00007fff60f52000 C:\Windows\System32\win32u.dll >>> >>> 0x00007fff61ac0000 - 0x00007fff61aeb000 C:\Windows\System32\GDI32.dll >>> >>> 0x00007fff45910000 - 0x00007fff45baa000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\COMCTL32.dll >>> >>> 0x00007fff60c30000 - 0x00007fff60d3b000 C:\Windows\System32\gdi32full.dll >>> >>> 0x00007fff62fd0000 - 0x00007fff6306e000 C:\Windows\System32\msvcrt.dll >>> >>> 0x00007fff610c0000 - 0x00007fff6115d000 C:\Windows\System32\msvcp_win.dll >>> >>> 0x00007fff61160000 - 0x00007fff61190000 C:\Windows\System32\IMM32.DLL >>> >>> 0x00007fff5b580000 - 0x00007fff5b58c000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\vcruntime140_1.dll >>> >>> 0x00007fff44fa0000 - 0x00007fff4502d000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\msvcp140.dll >>> >>> 0x00007ffefad70000 - 0x00007ffefb920000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server\jvm.dll >>> >>> 0x00007fff61ef0000 - 0x00007fff61f9c000 C:\Windows\System32\ADVAPI32.dll >>> >>> 0x00007fff61cf0000 - 0x00007fff61d8b000 C:\Windows\System32\sechost.dll >>> >>> 0x00007fff62b60000 - 0x00007fff62c8a000 C:\Windows\System32\RPCRT4.dll >>> >>> 0x00007fff61ee0000 - 0x00007fff61ee8000 C:\Windows\System32\PSAPI.DLL >>> >>> 0x00007fff2dc20000 - 0x00007fff2dc29000 C:\Windows\SYSTEM32\WSOCK32.dll >>> >>> 0x00007fff54b80000 - 0x00007fff54b8a000 C:\Windows\SYSTEM32\VERSION.dll >>> >>> 0x00007fff518e0000 - 0x00007fff51907000 C:\Windows\SYSTEM32\WINMM.dll >>> >>> 0x00007fff61bd0000 - 0x00007fff61c3b000 C:\Windows\System32\WS2_32.dll >>> >>> 0x00007fff5f060000 - 0x00007fff5f072000 C:\Windows\SYSTEM32\kernel.appcore.dll >>> >>> 0x00007fff5b500000 - 0x00007fff5b50a000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\jimage.dll >>> >>> 0x00007fff5e430000 - 0x00007fff5e614000 C:\Windows\SYSTEM32\DBGHELP.DLL >>> >>> 0x00007fff45170000 - 0x00007fff4519c000 C:\Windows\SYSTEM32\dbgcore.DLL >>> >>> 0x00007fff60d40000 - 0x00007fff60dc3000 C:\Windows\System32\bcryptPrimitives.dll >>> >>> 0x00007fff44f70000 - 0x00007fff44f95000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\java.dll >>> >>> 0x00007fff612c0000 - 0x00007fff619ff000 C:\Windows\System32\SHELL32.dll >>> >>> 0x00007fff5e620000 - 0x00007fff5edb0000 C:\Windows\SYSTEM32\windows.storage.dll >>> >>> 0x00007fff62650000 - 0x00007fff629a5000 C:\Windows\System32\combase.dll >>> >>> 0x00007fff60280000 - 0x00007fff602ae000 C:\Windows\SYSTEM32\Wldp.dll >>> >>> 0x00007fff61c40000 - 0x00007fff61ced000 C:\Windows\System32\SHCORE.dll >>> >>> 0x00007fff62f70000 - 0x00007fff62fc5000 C:\Windows\System32\shlwapi.dll >>> >>> 0x00007fff60770000 - 0x00007fff6078f000 C:\Windows\SYSTEM32\profapi.dll >>> >>> 0x00007fff44f10000 - 0x00007fff44f29000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\net.dll >>> >>> 0x00007fff5ada0000 - 0x00007fff5aeac000 C:\Windows\SYSTEM32\WINHTTP.dll >>> >>> 0x00007fff5ffe0000 - 0x00007fff6004a000 C:\Windows\system32\mswsock.dll >>> >>> 0x00007fff28650000 - 0x00007fff28665000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\nio.dll >>> >>> 0x00007ffeda3b0000 - 0x00007ffede7d1000 C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\libclang.dll >>> >>> 0x00007fff62ea0000 - 0x00007fff62f6d000 C:\Windows\System32\OLEAUT32.dll >>> >>> 0x00007fff61190000 - 0x00007fff612ba000 C:\Windows\System32\ole32.dll >>> >>> 0x00007fff5dac0000 - 0x00007fff5db5e000 C:\Windows\system32\uxtheme.dll >>> >>> 0x00007fff61e30000 - 0x00007fff61ed9000 C:\Windows\System32\clbcatq.dll >>> >>> 0x00007fff601d0000 - 0x00007fff601e8000 C:\Windows\SYSTEM32\CRYPTSP.dll >>> >>> 0x00007fff5f8c0000 - 0x00007fff5f8f4000 C:\Windows\system32\rsaenh.dll >>> >>> 0x00007fff60930000 - 0x00007fff60957000 C:\Windows\System32\bcrypt.dll >>> >>> 0x00007fff60730000 - 0x00007fff6075e000 C:\Windows\SYSTEM32\USERENV.dll >>> >>> 0x00007fff601f0000 - 0x00007fff601fc000 C:\Windows\SYSTEM32\CRYPTBASE.dll >>> >>> 0x00007fff5fc80000 - 0x00007fff5fcbb000 C:\Windows\SYSTEM32\IPHLPAPI.DLL >>> >>> 0x00007fff62550000 - 0x00007fff62558000 C:\Windows\System32\NSI.dll >>> >>> 0x00007fff55080000 - 0x00007fff55097000 C:\Windows\SYSTEM32\dhcpcsvc6.DLL >>> >>> 0x00007fff55060000 - 0x00007fff5507d000 C:\Windows\SYSTEM32\dhcpcsvc.DLL >>> >>> 0x00007fff5fcd0000 - 0x00007fff5fd9b000 C:\Windows\SYSTEM32\DNSAPI.dll >>> >>> dbghelp: loaded successfully - version: 4.0.5 - missing functions: none >>> >>> symbol engine: initialized successfully - sym options: 0x614 - pdb path: .;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin;C:\Windows\SYSTEM32;C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e;C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17\bin\server >>> >>> VM Arguments: >>> >>> jvm_args: -Dapplication.home=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 --enable-native-access=jdk.incubator.jextract -Xms8m -Djdk.module.main=jdk.incubator.jextract >>> >>> java_command: jdk.incubator.jextract/jdk.incubator.jextract.JextractTool -I C:\Users\Martin\Dev\jzy3d\external\freeglut\include -l opengl32 -l glu32 -l freeglut -t opengl -- C:\Users\Martin\Dev\jzy3d\external\freeglut\include\GL\freeglut.h >>> >>> java_class_path (initial): >>> >>> Launcher Type: SUN_STANDARD >>> >>> [Global flags] >>> >>> intx CICompilerCount = 4 {product} {ergonomic} >>> >>> uint ConcGCThreads = 2 {product} {ergonomic} >>> >>> uint G1ConcRefinementThreads = 8 {product} {ergonomic} >>> >>> size_t G1HeapRegionSize = 2097152 {product} {ergonomic} >>> >>> uintx GCDrainStackTargetSize = 64 {product} {ergonomic} >>> >>> size_t InitialHeapSize = 8388608 {product} {command line} >>> >>> size_t MarkStackSize = 4194304 {product} {ergonomic} >>> >>> size_t MaxHeapSize = 4223664128 {product} {ergonomic} >>> >>> size_t MaxNewSize = 2533359616 {product} {ergonomic} >>> >>> size_t MinHeapDeltaBytes = 2097152 {product} {ergonomic} >>> >>> size_t MinHeapSize = 8388608 {product} {command line} >>> >>> uintx NonNMethodCodeHeapSize = 5839372 {pd product} {ergonomic} >>> >>> uintx NonProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} >>> >>> uintx ProfiledCodeHeapSize = 122909434 {pd product} {ergonomic} >>> >>> uintx ReservedCodeCacheSize = 251658240 {pd product} {ergonomic} >>> >>> bool SegmentedCodeCache = true {product} {ergonomic} >>> >>> size_t SoftMaxHeapSize = 4223664128 {manageable} {ergonomic} >>> >>> bool UseCompressedClassPointers = true {product lp64_product} {ergonomic} >>> >>> bool UseCompressedOops = true {product lp64_product} {ergonomic} >>> >>> bool UseG1GC = true {product} {ergonomic} >>> >>> bool UseLargePagesIndividualAllocation = false {pd product} {ergonomic} >>> >>> Logging: >>> >>> Log output configuration: >>> >>> #0: stdout all=warning uptime,level,tags >>> >>> #1: stderr all=off uptime,level,tags >>> >>> Environment Variables: >>> >>> JAVA_HOME=C:\Program Files\Java\openjdk-17-panama+3-167_windows-x64_bin\jdk-17 >>> >>> PATH=C:\Program Files\Zulu\zulu-11\bin\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Program Files (x86)\apache-ant-1.9.16\bin;C:\Program Files\CMake\bin;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\7-Zip;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\gawk-3.1.6-1-bin\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\bin;C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin;C:\Users\Martin\AppData\Local\Microsoft\WindowsApps;C:\Users\Martin\AppData\Local\atom\bin;C:\Program Files (x86)\apache-maven-3.8.3\bin;C:\Users\Martin\.dotnet\tools >>> >>> USERNAME=Martin >>> >>> OS=Windows_NT >>> >>> PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 140 Stepping 1, GenuineIntel >>> >>> --------------- S Y S T E M --------------- >>> >>> OS: >>> >>> Windows 10 , 64 bit Build 19041 (10.0.19041.1348) >>> >>> OS uptime: 0 days 4:15 hours >>> >>> Hyper-V role detected >>> >>> CPU: total 8 (initial active 8) (4 cores per cpu, 2 threads per core) family 6 model 140 stepping 1 microcode 0x86, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, avx512f, avx512dq, avx512cd, avx512bw, avx512vl, sha, fma, vzeroupper, avx512_vpopcntdq, avx512_vpclmulqdq, avx512_vaes, avx512_vnni, clflush, clflushopt, clwb, avx512_vbmi2, avx512_vbmi, hv >>> >>> Memory: 4k page, system-wide physical 16107M (6064M free) >>> >>> TotalPageFile size 20971M (AvailPageFile size 8500M) >>> >>> current process WorkingSet (physical memory assigned to process): 136M, peak: 147M >>> >>> current process commit charge ("private bytes"): 177M, peak: 191M >>> >>> vm_info: OpenJDK 64-Bit Server VM (17-panama+3-167) for windows-amd64 JRE (17-panama+3-167), built on May 18 2021 13:10:19 by "mach5one" with MS VC++ 16.8 (VS2019) >>> >>> END. >>> >>> Sent with ProtonMail Secure Email. >>> >>> ??????? Original Message ??????? >>> >>> Le vendredi 12 novembre 2021 ? 15:47, Martin Pernollet martin.pernollet at protonmail.com a ?crit : >>> >>>> Thanks Jon, >>>> >>>> MinGW did not create a GL.dll file but rather libfreeglut.dll so I changed to >>>> >>>> public class glut_h extends glut_h_3 { >>>> >>>> static { >>>> >>>> System.loadLibrary("libfreeglut"); >>>> >>>> But it still fails, this time due to unresolved dependencies. Dependency Walker reveals tons of unreachable DLL (see screenshot). >>>> >>>> This failed attempt is documented here https://urldefense.com/v3/https://github.com/jzy3d/panama-gl/issues/11;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI_ssFZQS$ >>>> >>>> I'll follow your suggestion and update documentation and notify you once I got it working. >>>> >>>> ??????? Original Message ??????? >>>> >>>> Le vendredi 12 novembre 2021 ? 15:17, Jorn Vernee jorn.vernee at oracle.com a ?crit : >>>> >>>>> Hi Martin, >>>>> >>>>> Thanks for testing this! >>>>> >>>>> The UnsatisfiedLinkError is not from code looking for a header file, >>>>> >>>>> it's from looking for a library/.dll file named GL.dll. On Windows >>>>> >>>>> though, freeglut needs the opengl libraries that come bundled with >>>>> >>>>> Windows (found in C:\Windows\System32), named opengl32 and glu32. The >>>>> >>>>> script should already add -l flags for those. >>>>> >>>>> WRT the jextract error you see. >>>>> >>>>> I have not tried to run the sample with freeglut installed through MingW >>>>> >>>>> yet. I instead used the freeglut package for MSVC here: >>>>> >>>>> https://urldefense.com/v3/https://www.transmissionzero.co.uk/software/freeglut-devel/;!!ACWV5N9M2RV99hQ!fnOA3p1wMORyuiny8V93rJRoIehHZT0VxEY6GHHIe8kIriT-w4LBQMhYI2nUkNV_$ extracted >>>>> >>>>> that in some folder, and the pointed freeglutPath at that folder. >>>>> >>>>> Note that jextract is using clang underneath to do the parsing. I know >>>>> >>>>> clang works pretty well with MSVC/Windows SDK header files, but I'm >>>>> >>>>> guessing it can not understand the MingW headers, looking at your error. >>>>> >>>>> I think it's having problems with __MINGW_NOTHROW and >>>>> >>>>> __MINGW_ATTRIB_NORETURN, which look like compiler builtins. >>>>> >>>>> I'd suggest trying the freeglut package I linked to instead, together >>>>> >>>>> with the Windows SDK headers (which clang should find automatically), >>>>> >>>>> and taking MingW headers out of the equation for now. We should probably >>>>> >>>>> create a README for that sample to include instructions on how to get >>>>> >>>>> freeglut. >>>>> >>>>> Note that on top of that, you will also have to change Teapot.java to >>>>> >>>>> account for a change in parameter names resulting in slightly different >>>>> >>>>> code being generated by jextract [1]. >>>>> >>>>> HTH, >>>>> >>>>> Jorn >>>>> >>>>> [1] : >>>>> >>>>> diff --git a/opengl/Teapot.java b/opengl/Teapot.java >>>>> >>>>> index 22d1f44..d5eb786 100644 >>>>> >>>>> --- a/opengl/Teapot.java >>>>> >>>>> +++ b/opengl/Teapot.java >>>>> >>>>> @@ -79,8 +79,8 @@ public class Teapot { >>>>> >>>>> glutInitWindowSize(500, 500); >>>>> >>>>> glutCreateWindow(allocator.allocateUtf8String("Hello Panama!")); >>>>> >>>>> var teapot = new Teapot(allocator); >>>>> >>>>> -??????????? var displayStub = >>>>> >>>>> glutDisplayFunc$func.allocate(teapot::display, scope); >>>>> >>>>> -??????????? var idleStub = glutIdleFunc$func.allocate(teapot::onIdle, >>>>> >>>>> scope); >>>>> >>>>> +??????????? var displayStub = >>>>> >>>>> glutDisplayFunc$callback.allocate(teapot::display, scope); >>>>> >>>>> +??????????? var idleStub = >>>>> >>>>> glutIdleFunc$callback.allocate(teapot::onIdle, scope); >>>>> >>>>> glutDisplayFunc(displayStub); >>>>> >>>>> glutIdleFunc(idleStub); >>>>> >>>>> glutMainLoop(); >>>>> >>>>> On 12/11/2021 13:01, Martin Pernollet wrote: >>>>> >>>>>> Thanks for your answer. I tried running on Windows an OpenGL binding generated on MacOS, and it fails on much simpler things. The glut_h file from Mac starts with lib names and path that are not relevant for Windows : >>>>>> >>>>>> public class glut_h extends glut_h_3 { >>>>>> >>>>>> static { >>>>>> >>>>>> System.loadLibrary("GL"); >>>>>> >>>>>> System.load("/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT"); >>>>>> >>>>>> } >>>>>> >>>>>> while on Windows the path is "C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include" when using Freeglut built with MinGW. >>>>>> >>>>>> Fixing manually in the generated glut_h won't help : Exception in thread "main" java.lang.UnsatisfiedLinkError: no GL in java.library.path: C:\Mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\include despite I really got a GL folder under the include dir. >>>>>> >>>>>> So I got back to Sundararajana samples on github to generate the bindings and got stuck by a surprising JExtract exception : >>>>>> >>>>>> PS C:\Users\Martin\Dev\jzy3d\external\panama-jextract-samples\opengl> ./compile_windows.ps1 >>>>>> >>>>>> [...] >>>>>> >>>>>> freeglutPath: C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32 >>>>>> >>>>>> WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract >>>>>> >>>>>> C:/Mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/x86_64-w64-mingw32\include\stdlib.h:360:47: error: expected ';' after top level declarator >>>>>> >>>>>> ERROR: jextract exited with non-zero exit code: 3 >>>>>> >>>>>> Whereas I can not see anything wrong in stdlib.h which is as follow around line 360 : >>>>>> >>>>>> 358: #ifndef _CRT_TERMINATE_DEFINED >>>>>> >>>>>> 359: #define _CRT_TERMINATE_DEFINED >>>>>> >>>>>> 360: void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; >>>>>> >>>>>> 361: void __cdecl __MINGW_NOTHROW _exit(int _Code) __MINGW_ATTRIB_NORETURN; >>>>>> >>>>>> I should mention that >>>>>> >>>>>> - I built and installed freeglut since JExtract command for Windows wants it. I verified I could build and run a simple program showing a triangle so I think that my Freeglut install in MinGW64 is correct. >>>>>> - I verified GCC and G++ are callable from Powershell >>>>>> - The internet sometime suggest to enclose such problematic lines in a #if defined __cplusplus / #endif block but I think I should not have to edit stdlib.h myself. >>>>>> >>>>>> Is this stdlib error something some of you already faced? How did you fix? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Sent with ProtonMail Secure Email. >>>>>> >>>>>> ??????? Original Message ??????? >>>>>> >>>>>> Le lundi 18 octobre 2021 ? 11:29, Rado Smogura mail at smogura.eu a ?crit : >>>>>> >>>>>>> Hi Martin, >>>>>>> >>>>>>> Let me answer the last questions about JExtract and .h files for every >>>>>>> >>>>>>> platform. >>>>>>> >>>>>>> It may be needed to do separate bindings, unless you can prove >>>>>>> >>>>>>> otherwise. The specifications provides .h files and names, but may not >>>>>>> >>>>>>> be clear if, >>>>>>> >>>>>>> - given name is variable, or define >>>>>>> >>>>>>> - values set to const / variable >>>>>>> >>>>>>> - expr() is method or define >>>>>>> >>>>>>> There was one experiment with POSIX, where even so standard things like >>>>>>> >>>>>>> net may differ on values assigned to DEFINED between Linux & OSX. >>>>>>> >>>>>>> Roughly speaking GL_CONST_X can be 1 on one system and 2 on the other, >>>>>>> >>>>>>> and this values will be "inlined" into extracted code. >>>>>>> >>>>>>> However how exactly is with OpenGL I don't know. >>>>>>> >>>>>>> Kind regards, >>>>>>> >>>>>>> Rado >>>>>>> >>>>>>> On 17.10.2021 15:20, Martin Pernollet wrote: >>>>>>> >>>>>>> >>>>>>>> Report about more intensive use of foreign function API >>>>>>>> >>>>>>>> I have plugged mouse control and automated rotation to the PanamaGL prototype [0]. I have let a native frame opened for an hour and didn?t notice any crash. The only JVM crashes I encountered were when I got an exception in a callback due to me. As Jorn said, a complete stack print would be helpful to locate where the bug comes from. One can reproduce crashes without exception with the teapot example modified as follow : >>>>>>>> >>>>>>>> void onIdle() { >>>>>>>> >>>>>>>> throw new IllegalArgumentException("Teapot does not support coffee"); >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> My CPU is busy (60%) but this is normal : this prototype uses glutMainLoop(), which will let the GPU run and invoke CPU/JVM at each frame. At each frame, Jzy3D will invoke all OpenGL methods to render geometries in immediate mode (a.k.a fixed function pipeline). There are ways to do things more efficiently in Jzy3D with a single communication between GPU and CPU at program start, but I think it is better to stick on such non-efficient way of rendering for the purpose of challenging JEP-412. >>>>>>>> >>>>>>>> I did not implement a couple of things for the prototype (text, automatic HiDPI detection, image overlays, screenshots, etc) because there are harder questions that I would like to discuss before. >>>>>>>> >>>>>>>> Integration in an AWT Canvas >>>>>>>> >>>>>>>> Embedding a GL renderer into an existing AWT application could be done by rendering the image offscreen, fetching it to convert as a BufferedImage and then add it in an AWT Canvas. This is however inefficient since the pixels will go from GPU to CPU and then back to GPU. >>>>>>>> >>>>>>>> It would be more efficient to execute GL code in GPU in a viewport relating to the canvas where we intend to draw. Beside being more efficient, this would also comply with the need of OpenGL to be invoked by a single thread. The authors of JOGL did this by defining a GLEventListener[1] interface that must be registered on a GLCanvas. The GLCanvas will invoke the GLEventListener, and the implementation of GLEventListener.display must define what to draw, e.g. a teapot, a collection of polygons, etc. >>>>>>>> >>>>>>>> I hence would like to hook where a Canvas gets rendered by AWT and execute GL code from there. I found this package [2] to be instructive for the native OpenGL side, SunGraphics2D lead me to PixelDrawPipe, then CompositeCRenderer where I get a bit lost for now as it relies on SunGraphics2D back. I would enjoy any suggestion clarifying who actually draws an AWT widget, and where is the link between Graphics2D and OpenGL. >>>>>>>> >>>>>>>> Beside these technical questions I have an historical one : JOGL was initially created by Sun and I presume Java3D relied on it when it was released in 1998. Java3D was dropped in 2004 from JDK and JOGL was given to the community. Does someone know what the reasons were? I fear writing something similar to what was done 20 years ago would fail the same way :) >>>>>>>> >>>>>>>> I know that Apple has shifted to Metal on MacOS, that JDK now has the ability to use it for rendering and that I would have to deal with OpenGL + Metal that should fit under the same interface (implementing an OpenGL interface with Metal would probably be the best way). >>>>>>>> >>>>>>>> More practical questions about JExtract >>>>>>>> >>>>>>>> I presume I should not have to build an OpenGL binding with JExtract for each OS/Version, because OpenGL is a specification and all computer vendors should provide .h that follow the same specs. So my understanding is that JExtract should in theory be ran for each OS/Version, but in practice can be ran once on my computer and will be OK for Windows and Linux for the OpenGL case. >>>>>>>> >>>>>>>> Last, I wonder if exposing OpenGL through JExtract from an AWT Canvas would be compatible with using OpenGL to render usual AWT widgets with native OpenGL inside the JVM? >>>>>>>> >>>>>>>> Thanks for reading! >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>> [0] https://urldefense.com/v3/https://github.com/jzy3d/panama-gl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8bHkQ00p$ >>>>>>>> >>>>>>>> [1] https://urldefense.com/v3/https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLEventListener.html;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8ROseeEa$ >>>>>>>> >>>>>>>> [2] https://urldefense.com/v3/https://github.com/openjdk/jdk/tree/master/src/java.desktop/share/native/common/java2d/opengl;!!ACWV5N9M2RV99hQ!Y8ZS9vrOr-YuUd_CFsgfhGO3aSXk4ne1wkwSCaMl0iDG2u41mhMU1YSO8WkFrawU$ From paul.sandoz at oracle.com Mon Nov 15 19:00:11 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 15 Nov 2021 19:00:11 +0000 Subject: [vectorIntrinsics+compress] RFR: Compress JavaDoc. In-Reply-To: References: Message-ID: Doh! thanks, applied. Paul. > On Nov 13, 2021, at 10:49 AM, John Rose wrote: > > Good but in @code Mask should be VectorMask. > >> On Nov 12, 2021, at 1:32 PM, Sandhya Viswanathan wrote: >> >> ?On Fri, 12 Nov 2021 19:00:44 GMT, Paul Sandoz wrote: >> >>> Add a little summary of compress/expand in the cross-lane section of the `Vector` class doc. >> >> Looks good to me. >> >> ------------- >> >> Marked as reviewed by sviswanathan (Committer). >> >> PR: https://git.openjdk.java.net/panama-vector/pull/162 From psandoz at openjdk.java.net Mon Nov 15 19:07:26 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 15 Nov 2021 19:07:26 GMT Subject: [vectorIntrinsics+compress] RFR: Compress JavaDoc. [v2] In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 19:04:07 GMT, Paul Sandoz wrote: >> Add a little summary of compress/expand in the cross-lane section of the `Vector` class doc. > > Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: > > Use correct class name, VectorMask src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java line 1045: > 1043: * methods, which select up to {@code VLENGTH} lanes from an > 1044: * input vector, and assemble them in lane order. The selection of lanes > 1045: * is controlled by a {@code Mask}, with set lane elements mapping, by Suggestion: * is controlled by a {@code VectorMask}, with set lane elements mapping, by ------------- PR: https://git.openjdk.java.net/panama-vector/pull/162 From psandoz at openjdk.java.net Mon Nov 15 19:07:21 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 15 Nov 2021 19:07:21 GMT Subject: [vectorIntrinsics+compress] RFR: Compress JavaDoc. [v2] In-Reply-To: References: Message-ID: > Add a little summary of compress/expand in the cross-lane section of the `Vector` class doc. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Use correct class name, VectorMask ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/162/files - new: https://git.openjdk.java.net/panama-vector/pull/162/files/a8993c63..3c9c2626 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=162&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=162&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-vector/pull/162.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/162/head:pull/162 PR: https://git.openjdk.java.net/panama-vector/pull/162 From psandoz at openjdk.java.net Mon Nov 15 19:07:28 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 15 Nov 2021 19:07:28 GMT Subject: [vectorIntrinsics+compress] Integrated: Compress JavaDoc. In-Reply-To: References: Message-ID: <_ajEKNMpT9eKxiQ2shIkrojZN1rg82YaES4i5b3nBIA=.e79f4e52-222e-4daf-b6e2-41ba9274a4cc@github.com> On Fri, 12 Nov 2021 19:00:44 GMT, Paul Sandoz wrote: > Add a little summary of compress/expand in the cross-lane section of the `Vector` class doc. This pull request has now been integrated. Changeset: b4bb8f23 Author: Paul Sandoz URL: https://git.openjdk.java.net/panama-vector/commit/b4bb8f23acd554a68a0b5e8a35f936cb1bc17b93 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Compress JavaDoc. Reviewed-by: sviswanathan ------------- PR: https://git.openjdk.java.net/panama-vector/pull/162 From sviswanathan at openjdk.java.net Mon Nov 15 23:35:44 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Mon, 15 Nov 2021 23:35:44 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v3] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: <5dxUI_4ttrXWo-IpqnSVErt6XKd6B8SJuhHF9zNGDNM=.dbc4f085-bf00-4511-b00e-e8fc6b5dd327@github.com> On Tue, 9 Nov 2021 16:14:26 GMT, Mai ??ng Qu?n Anh wrote: >> Hi, >> This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. >> Thank you very much. > > Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: > > - support for non-bmi, some refinement > - restore VectorStoreMaskNode, move logic to backend src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4079: > 4077: movl(dst, -1); > 4078: bsrq(tmp, tmp); > 4079: cmov32(Assembler::notZero, dst, tmp); We could use LZCNT here on platforms that support it. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4102: > 4100: assert(vec_enc == AVX_128bit && VM_Version::supports_avx() || > 4101: vec_enc == AVX_256bit && (VM_Version::supports_avx2() || type2aelembytes(bt) >= 4), ""); > 4102: Add an assert here that dst is same as tmp for Op_VectorMaskToLong. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4151: > 4149: movl(dst, -1); > 4150: bsrl(tmp, tmp); > 4151: cmov32(Assembler::notZero, dst, tmp); We could use LZCNT here on platforms that support it. src/hotspot/cpu/x86/x86.ad line 8688: > 8686: int vlen_enc = vector_length_encoding(this, $mask); > 8687: __ vector_mask_operation(opcode, noreg, $mask$$XMMRegister, $xtmp$$XMMRegister, > 8688: $dst$$Register, mask_len, mbt, vlen_enc); For all the tolong instructs, it is better to pass 2nd argument also as $dst$$Register instead of noreg in vector_mask_operation. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Tue Nov 16 07:59:59 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Tue, 16 Nov 2021 07:59:59 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v3] In-Reply-To: <5dxUI_4ttrXWo-IpqnSVErt6XKd6B8SJuhHF9zNGDNM=.dbc4f085-bf00-4511-b00e-e8fc6b5dd327@github.com> References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> <5dxUI_4ttrXWo-IpqnSVErt6XKd6B8SJuhHF9zNGDNM=.dbc4f085-bf00-4511-b00e-e8fc6b5dd327@github.com> Message-ID: On Mon, 15 Nov 2021 19:15:34 GMT, Sandhya Viswanathan wrote: >> Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: >> >> - support for non-bmi, some refinement >> - restore VectorStoreMaskNode, move logic to backend > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4079: > >> 4077: movl(dst, -1); >> 4078: bsrq(tmp, tmp); >> 4079: cmov32(Assembler::notZero, dst, tmp); > > We could use LZCNT here on platforms that support it. Thank you very much for your reviews and suggestions. I have measured both approaches. While these provide similar performance on Intels with the `lzcnt` offers better throughput at the exchange of slightly worse latency. The situation is quite different on Amds due to the inefficiency of `bsf` in comparison with `lzcnt`. So I think using `lzcnt` where possible would be more preferable. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Tue Nov 16 08:16:11 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Tue, 16 Nov 2021 08:16:11 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v4] In-Reply-To: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: > Hi, > This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. > Thank you very much. Mai ??ng Qu?n Anh has updated the pull request incrementally with one additional commit since the last revision: use duplicate dst instead of noreg, use lzcnt for hardwares support it ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/158/files - new: https://git.openjdk.java.net/panama-vector/pull/158/files/d3249aee..de9de8f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=158&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=158&range=02-03 Stats: 37 lines in 3 files changed: 7 ins; 1 del; 29 mod Patch: https://git.openjdk.java.net/panama-vector/pull/158.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/158/head:pull/158 PR: https://git.openjdk.java.net/panama-vector/pull/158 From sviswanathan at openjdk.java.net Tue Nov 16 17:46:15 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 16 Nov 2021 17:46:15 GMT Subject: [vectorIntrinsics+fp16] RFR: Merge panama-vector:vectorIntrinsics Message-ID: Bringing the vectorIntrinsics+fp16 branch up to date with vectorIntrinsics. It is a clean merge. Best Regards, Sandhya ------------- Commit messages: - 8275025: Unable to inline vectmask convert - 8274569: X86 backend related incorrectness issues in legacy store mask patterns - Fix typo in VectorMask.laneIsSet - 8274631: assert(false) failed: bad AD file with -XX:UseKNLSetting - Merge panama-vector:master - 8274509: Remove stray * and stylistic . from doc comments - 8274453: (sctp) com/sun/nio/sctp/SctpChannel/CloseDescriptors.java test should be resilient to lsof warnings - 8274330: Incorrect encoding of the DistributionPointName object in IssuingDistributionPointExtension - 8272562: C2: assert(false) failed: Bad graph detected in build_loop_late - 8274340: [BACKOUT] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references - ... and 1355 more: https://git.openjdk.java.net/panama-vector/compare/e8e72698...d67afb1e The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/panama-vector/pull/163/files Stats: 220954 lines in 3998 files changed: 145232 ins; 51592 del; 24130 mod Patch: https://git.openjdk.java.net/panama-vector/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/163/head:pull/163 PR: https://git.openjdk.java.net/panama-vector/pull/163 From psandoz at openjdk.java.net Tue Nov 16 18:26:59 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 16 Nov 2021 18:26:59 GMT Subject: [vectorIntrinsics+fp16] RFR: Merge panama-vector:vectorIntrinsics In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 17:37:38 GMT, Sandhya Viswanathan wrote: > Bringing the vectorIntrinsics+fp16 branch up to date with vectorIntrinsics. > It is a clean merge. > > Best Regards, > Sandhya Marked as reviewed by psandoz (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/163 From mcimadamore at openjdk.java.net Tue Nov 16 19:10:17 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 16 Nov 2021 19:10:17 GMT Subject: [foreign-memaccess+abi] RFR: 8275647: Enable multi-register return values for optimized upcall stubs In-Reply-To: References: Message-ID: <2TAMBVGoOmwhFWgHXO65aD21Jk8D8zGssgX0VX5maCA=.e83cee9d-20b2-4552-ab9e-b79708e975f4@github.com> On Tue, 2 Nov 2021 19:07:45 GMT, Jorn Vernee wrote: > Hi, > > After we've added multi-register return support to native invokers, this patch does the same for optimized upcall stubs. The strategy is very similar: the caller (in this case the upcall stub) allocates a return buffer in which the return values are stored, and then after the upcall shuffles the return values from the buffer into the right registers. > > This patch also removes the buffered invocation strategy for upcalls, and all related code, such as BufferLayout. > > ~Note, in it's current state this patch will disable regress AArch64 since optimized upcalls are not implemented there yet. i.e. this PR is blocked by: https://bugs.openjdk.java.net/browse/JDK-8275646~ > > Jorn Looks very good. I've tested the changes on my machine, and all works fine. src/hotspot/cpu/arm/universalUpcallHandle_arm.cpp line 28: > 26: #include "utilities/debug.hpp" > 27: > 28: address ProgrammableUpcallHandler::generate_optimized_upcall_stub(jobject receiver, Method* entry, is the name "optimized" still carrying meaning in the new VM code? ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/608 From sviswanathan at openjdk.java.net Tue Nov 16 19:13:20 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 16 Nov 2021 19:13:20 GMT Subject: [vectorIntrinsics+fp16] RFR: Merge panama-vector:vectorIntrinsics [v2] In-Reply-To: References: Message-ID: > Bringing the vectorIntrinsics+fp16 branch up to date with vectorIntrinsics. > It is a clean merge. > > Best Regards, > Sandhya Sandhya Viswanathan 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. ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/163/files - new: https://git.openjdk.java.net/panama-vector/pull/163/files/d67afb1e..d67afb1e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=163&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=163&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/163/head:pull/163 PR: https://git.openjdk.java.net/panama-vector/pull/163 From sviswanathan at openjdk.java.net Tue Nov 16 19:13:25 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 16 Nov 2021 19:13:25 GMT Subject: [vectorIntrinsics+fp16] Integrated: Merge panama-vector:vectorIntrinsics In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 17:37:38 GMT, Sandhya Viswanathan wrote: > Bringing the vectorIntrinsics+fp16 branch up to date with vectorIntrinsics. > It is a clean merge. > > Best Regards, > Sandhya This pull request has now been integrated. Changeset: 302d35fc Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/panama-vector/commit/302d35fced1b7027fe6cd8a22d94d7b204fd27a6 Stats: 220954 lines in 3998 files changed: 145232 ins; 51592 del; 24130 mod Merge panama-vector:vectorIntrinsics Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/panama-vector/pull/163 From paul.sandoz at oracle.com Tue Nov 16 19:31:21 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 16 Nov 2021 19:31:21 +0000 Subject: java 17 libsvml.so conflict with user app In-Reply-To: References: Message-ID: <04033804-E0C2-429F-8F16-ECDD57CFDD07@oracle.com> This has no been fixed and back ported by Sandhya. Paul. > On Oct 25, 2021, at 4:43 PM, Vitaly Davidovich wrote: > > Hi all, > > We're testing some of our code on Java 17 (17.0.1)/linux and hit an issue > related to libsvml.so. It seems this library is now part of 17 to support > the (incubating) Vector API. We have a java library backed (via JNI) by > NAG, which itself links against libsvml.so. The issue arises due to > java.lang.UnsatisfiedLinkError when our java library is trying to call into > a NAG function which in turn is looking for a certain symbol from libsvml > (__svml_exp2_ha_mask in particular). > > It looks like the JDK is eagerly loading symbols from its packaged libsvml > (is there a way to disable that for now?). That version of the library is > also in conflict with the one we want to load, as witnessed by the missing > symbol (there're probably others but we stopped testing at this point). > > Is this a known issue/compatibility hazard? Happy to hear thoughts/opinions > on this and provide further info, if needed. > > Thanks From paul.sandoz at oracle.com Tue Nov 16 19:32:05 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 16 Nov 2021 19:32:05 +0000 Subject: java 17 libsvml.so conflict with user app In-Reply-To: <04033804-E0C2-429F-8F16-ECDD57CFDD07@oracle.com> References: <04033804-E0C2-429F-8F16-ECDD57CFDD07@oracle.com> Message-ID: Grrr typo: This has *now* been fixed and back ported by Sandhya. Paul. > On Nov 16, 2021, at 11:31 AM, OracleE wrote: > > This has no been fixed and back ported by Sandhya. > > Paul. > >> On Oct 25, 2021, at 4:43 PM, Vitaly Davidovich wrote: >> >> Hi all, >> >> We're testing some of our code on Java 17 (17.0.1)/linux and hit an issue >> related to libsvml.so. It seems this library is now part of 17 to support >> the (incubating) Vector API. We have a java library backed (via JNI) by >> NAG, which itself links against libsvml.so. The issue arises due to >> java.lang.UnsatisfiedLinkError when our java library is trying to call into >> a NAG function which in turn is looking for a certain symbol from libsvml >> (__svml_exp2_ha_mask in particular). >> >> It looks like the JDK is eagerly loading symbols from its packaged libsvml >> (is there a way to disable that for now?). That version of the library is >> also in conflict with the one we want to load, as witnessed by the missing >> symbol (there're probably others but we stopped testing at this point). >> >> Is this a known issue/compatibility hazard? Happy to hear thoughts/opinions >> on this and provide further info, if needed. >> >> Thanks > From paul.sandoz at oracle.com Tue Nov 16 19:46:11 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 16 Nov 2021 19:46:11 +0000 Subject: [vector-api] draft CSR for vector compress expand Message-ID: Hi, See here: https://bugs.openjdk.java.net/browse/JDK-8277156 Now that https://github.com/openjdk/jdk/pull/5873 has been integrated I think we can merge vectorIntrinsics+compress into vectorIntrinsics, perhaps after master is merged into vectorIntrinsics? Paul. From jvernee at openjdk.java.net Tue Nov 16 20:29:58 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 16 Nov 2021 20:29:58 GMT Subject: [foreign-memaccess+abi] RFR: 8275647: Enable multi-register return values for optimized upcall stubs In-Reply-To: <2TAMBVGoOmwhFWgHXO65aD21Jk8D8zGssgX0VX5maCA=.e83cee9d-20b2-4552-ab9e-b79708e975f4@github.com> References: <2TAMBVGoOmwhFWgHXO65aD21Jk8D8zGssgX0VX5maCA=.e83cee9d-20b2-4552-ab9e-b79708e975f4@github.com> Message-ID: On Tue, 16 Nov 2021 19:06:54 GMT, Maurizio Cimadamore wrote: >> Hi, >> >> After we've added multi-register return support to native invokers, this patch does the same for optimized upcall stubs. The strategy is very similar: the caller (in this case the upcall stub) allocates a return buffer in which the return values are stored, and then after the upcall shuffles the return values from the buffer into the right registers. >> >> This patch also removes the buffered invocation strategy for upcalls, and all related code, such as BufferLayout. >> >> ~Note, in it's current state this patch will disable regress AArch64 since optimized upcalls are not implemented there yet. i.e. this PR is blocked by: https://bugs.openjdk.java.net/browse/JDK-8275646~ >> >> Jorn > > src/hotspot/cpu/arm/universalUpcallHandle_arm.cpp line 28: > >> 26: #include "utilities/debug.hpp" >> 27: >> 28: address ProgrammableUpcallHandler::generate_optimized_upcall_stub(jobject receiver, Method* entry, > > is the name "optimized" still carrying meaning in the new VM code? Not really, but I thought I'd save the renaming for: https://bugs.openjdk.java.net/browse/JDK-8275648 ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/608 From jvernee at openjdk.java.net Tue Nov 16 20:29:59 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 16 Nov 2021 20:29:59 GMT Subject: [foreign-memaccess+abi] RFR: 8275647: Enable multi-register return values for optimized upcall stubs In-Reply-To: References: <2TAMBVGoOmwhFWgHXO65aD21Jk8D8zGssgX0VX5maCA=.e83cee9d-20b2-4552-ab9e-b79708e975f4@github.com> Message-ID: On Tue, 16 Nov 2021 20:26:06 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/arm/universalUpcallHandle_arm.cpp line 28: >> >>> 26: #include "utilities/debug.hpp" >>> 27: >>> 28: address ProgrammableUpcallHandler::generate_optimized_upcall_stub(jobject receiver, Method* entry, >> >> is the name "optimized" still carrying meaning in the new VM code? > > Not really, but I thought I'd save the renaming for: https://bugs.openjdk.java.net/browse/JDK-8275648 Doing it here wouldn't be such a hassle though. Though, there's also OptimizedEntryBlob which requires renaming. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/608 From mcimadamore at openjdk.java.net Tue Nov 16 21:26:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 16 Nov 2021 21:26:53 GMT Subject: [foreign-memaccess+abi] RFR: 8275647: Enable multi-register return values for optimized upcall stubs In-Reply-To: References: <2TAMBVGoOmwhFWgHXO65aD21Jk8D8zGssgX0VX5maCA=.e83cee9d-20b2-4552-ab9e-b79708e975f4@github.com> Message-ID: <0lmuy1OcbhZbq5zjDJI-T2ieSmCMhEqbw4wcGa2DKjY=.501371e2-b895-41d0-b342-90c26a13f5cd@github.com> On Tue, 16 Nov 2021 20:27:05 GMT, Jorn Vernee wrote: >> Not really, but I thought I'd save the renaming for: https://bugs.openjdk.java.net/browse/JDK-8275648 > > Doing it here wouldn't be such a hassle though. Though, there's also OptimizedEntryBlob which requires renaming. That's ok - ship it as is - we can rename later. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/608 From vitalyd at gmail.com Tue Nov 16 23:47:14 2021 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 16 Nov 2021 18:47:14 -0500 Subject: java 17 libsvml.so conflict with user app In-Reply-To: References: <04033804-E0C2-429F-8F16-ECDD57CFDD07@oracle.com> Message-ID: Thanks for the heads up Paul (and Sandhya for backporting). In case anyone reading this is interested, https://github.com/openjdk/jdk17u/commit/3e349b436628f430946b7c571aeab09e35392ed5 is the backport. On Tue, Nov 16, 2021 at 2:32 PM Paul Sandoz wrote: > Grrr typo: > > This has *now* been fixed and back ported by Sandhya. > > Paul. > > > On Nov 16, 2021, at 11:31 AM, OracleE wrote: > > > > This has no been fixed and back ported by Sandhya. > > > > Paul. > > > >> On Oct 25, 2021, at 4:43 PM, Vitaly Davidovich > wrote: > >> > >> Hi all, > >> > >> We're testing some of our code on Java 17 (17.0.1)/linux and hit an > issue > >> related to libsvml.so. It seems this library is now part of 17 to > support > >> the (incubating) Vector API. We have a java library backed (via JNI) by > >> NAG, which itself links against libsvml.so. The issue arises due to > >> java.lang.UnsatisfiedLinkError when our java library is trying to call > into > >> a NAG function which in turn is looking for a certain symbol from > libsvml > >> (__svml_exp2_ha_mask in particular). > >> > >> It looks like the JDK is eagerly loading symbols from its packaged > libsvml > >> (is there a way to disable that for now?). That version of the library > is > >> also in conflict with the one we want to load, as witnessed by the > missing > >> symbol (there're probably others but we stopped testing at this point). > >> > >> Is this a known issue/compatibility hazard? Happy to hear > thoughts/opinions > >> on this and provide further info, if needed. > >> > >> Thanks > > > > -- Sent from my phone From svkamath at openjdk.java.net Wed Nov 17 00:22:23 2021 From: svkamath at openjdk.java.net (Smita Kamath) Date: Wed, 17 Nov 2021 00:22:23 GMT Subject: [vectorIntrinsics+fp16] RFR: 8277304: Java support for FP16 Message-ID: Initial FP16 vectorAPI Java support. ------------- Commit messages: - Fixed space and tabs in code - FP16 Java support Changes: https://git.openjdk.java.net/panama-vector/pull/164/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=164&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277304 Stats: 9566 lines in 22 files changed: 9451 ins; 7 del; 108 mod Patch: https://git.openjdk.java.net/panama-vector/pull/164.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/164/head:pull/164 PR: https://git.openjdk.java.net/panama-vector/pull/164 From sandhya.viswanathan at intel.com Wed Nov 17 00:36:27 2021 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Wed, 17 Nov 2021 00:36:27 +0000 Subject: [vector-api] draft CSR for vector compress expand In-Reply-To: References: Message-ID: We will need help from Eric or Ningsheng for merging master into vectorIntrinsics. There is conflict in aarch64 files: both modified: src/hotspot/cpu/aarch64/aarch64_sve.ad both modified: src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 both modified: src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp both modified: src/hotspot/cpu/aarch64/register_aarch64.hpp both modified: test/hotspot/gtest/aarch64/asmtest.out.h Best Regards, Sandhya -----Original Message----- From: panama-dev On Behalf Of Paul Sandoz Sent: Tuesday, November 16, 2021 11:46 AM To: panama-dev Subject: [vector-api] draft CSR for vector compress expand Hi, See here: https://bugs.openjdk.java.net/browse/JDK-8277156 Now that https://github.com/openjdk/jdk/pull/5873 has been integrated I think we can merge vectorIntrinsics+compress into vectorIntrinsics, perhaps after master is merged into vectorIntrinsics? Paul. From sviswanathan at openjdk.java.net Wed Nov 17 01:17:57 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 17 Nov 2021 01:17:57 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v4] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: <35nX9qKjYdfHjbhRh1ngW6z4GglHxIgrY5fOfkCjRgY=.38cc2559-872e-4cc6-934f-d353086e2488@github.com> On Tue, 16 Nov 2021 08:16:11 GMT, Mai ??ng Qu?n Anh wrote: >> Hi, >> This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. >> Thank you very much. > > Mai ??ng Qu?n Anh has updated the pull request incrementally with one additional commit since the last revision: > > use duplicate dst instead of noreg, use lzcnt for hardwares support it src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4058: > 4056: void C2_MacroAssembler::vector_mask_operation(int opc, Register dst, KRegister mask, > 4057: int masklen, int masksize, int vec_enc) { > 4058: assert(VM_Version::supports_bmi1(), "Strange hardware"); Also need to check for supports_lzcnt(). src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4148: > 4146: break; > 4147: case Op_VectorMaskLastTrue: > 4148: if (VM_Version::supports_bmi1()) { This should be supports_lzcnt(). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From ngasson at openjdk.java.net Wed Nov 17 05:25:57 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 17 Nov 2021 05:25:57 GMT Subject: [foreign-memaccess+abi] RFR: 8275647: Enable multi-register return values for optimized upcall stubs In-Reply-To: References: Message-ID: <5I-2eLYds9Q5AWry_TUwkZkmz3hqP-hoaVkvLhO_n8Y=.14394174-eff6-49f0-8055-e8b2685b7bd8@github.com> On Tue, 2 Nov 2021 19:07:45 GMT, Jorn Vernee wrote: > Hi, > > After we've added multi-register return support to native invokers, this patch does the same for optimized upcall stubs. The strategy is very similar: the caller (in this case the upcall stub) allocates a return buffer in which the return values are stored, and then after the upcall shuffles the return values from the buffer into the right registers. > > This patch also removes the buffered invocation strategy for upcalls, and all related code, such as BufferLayout. > > ~Note, in it's current state this patch will disable regress AArch64 since optimized upcalls are not implemented there yet. i.e. this PR is blocked by: https://bugs.openjdk.java.net/browse/JDK-8275646~ > > Jorn AArch64 changes look fine. ------------- Marked as reviewed by ngasson (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/608 From njian at openjdk.java.net Wed Nov 17 07:42:04 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 17 Nov 2021 07:42:04 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master Message-ID: Resolve aarch64 conflicts. Also remove globalDefinitions_vecApi.hpp and it's reference in globalDefinitions.hpp as discussed in the review of https://github.com/openjdk/jdk/pull/5873. ------------- Commit messages: - Merge master into vectorIntrinsics - 8276787: Improve warning messages for -XX:+RecordDynamicDumpInfo - 8276609: Document setting property `jdk.serialFilter` to an invalid value throws `ExceptionInInitializerError` - 8275811: Incorrect instance to dispose - 8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes! - 8276231: ciReplay: SIGSEGV when replay compiling lambdas - 8277089: Use system binutils to build hsdis - 8276162: Optimise unsigned comparison pattern - 8276905: Use appropriate macosx_version_minimum value while compiling metal shaders - 8277119: Add asserts in GenericTaskQueueSet methods - ... and 597 more: https://git.openjdk.java.net/panama-vector/compare/83aaf148...9937e26d The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/panama-vector/pull/165/files Stats: 909496 lines in 2392 files changed: 469232 ins; 431206 del; 9058 mod Patch: https://git.openjdk.java.net/panama-vector/pull/165.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/165/head:pull/165 PR: https://git.openjdk.java.net/panama-vector/pull/165 From ningsheng.jian at arm.com Wed Nov 17 08:02:48 2021 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 17 Nov 2021 16:02:48 +0800 Subject: [vector-api] draft CSR for vector compress expand In-Reply-To: References: Message-ID: <4c1fef0b-9826-dc04-067b-69b9c40e6c83@arm.com> On 11/17/21 8:36 AM, Viswanathan, Sandhya wrote: > We will need help from Eric or Ningsheng for merging master into vectorIntrinsics. There is conflict in aarch64 files: > > both modified: src/hotspot/cpu/aarch64/aarch64_sve.ad > both modified: src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 > both modified: src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > both modified: src/hotspot/cpu/aarch64/register_aarch64.hpp > both modified: test/hotspot/gtest/aarch64/asmtest.out.h > I have created the merge PR: https://github.com/openjdk/panama-vector/pull/165 Thanks, Ningsheng From duke at openjdk.java.net Wed Nov 17 13:28:56 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Wed, 17 Nov 2021 13:28:56 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v4] In-Reply-To: <35nX9qKjYdfHjbhRh1ngW6z4GglHxIgrY5fOfkCjRgY=.38cc2559-872e-4cc6-934f-d353086e2488@github.com> References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> <35nX9qKjYdfHjbhRh1ngW6z4GglHxIgrY5fOfkCjRgY=.38cc2559-872e-4cc6-934f-d353086e2488@github.com> Message-ID: On Wed, 17 Nov 2021 01:13:13 GMT, Sandhya Viswanathan wrote: >> Mai ??ng Qu?n Anh has updated the pull request incrementally with one additional commit since the last revision: >> >> use duplicate dst instead of noreg, use lzcnt for hardwares support it > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4058: > >> 4056: void C2_MacroAssembler::vector_mask_operation(int opc, Register dst, KRegister mask, >> 4057: int masklen, int masksize, int vec_enc) { >> 4058: assert(VM_Version::supports_bmi1(), "Strange hardware"); > > Also need to check for supports_lzcnt(). We have separate checks for all `popcnt`, `lzcnt` and `tzcnt`, do you think the function should verify or just let the assembler throw after? > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4148: > >> 4146: break; >> 4147: case Op_VectorMaskLastTrue: >> 4148: if (VM_Version::supports_bmi1()) { > > This should be supports_lzcnt(). Oh right, thanks for noticing. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From sviswanathan at openjdk.java.net Wed Nov 17 17:51:33 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 17 Nov 2021 17:51:33 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 07:36:19 GMT, Ningsheng Jian wrote: > Resolve aarch64 conflicts. Also remove globalDefinitions_vecApi.hpp and it's reference in globalDefinitions.hpp as discussed in the review of https://github.com/openjdk/jdk/pull/5873. Marked as reviewed by sviswanathan (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/165 From sviswanathan at openjdk.java.net Wed Nov 17 18:02:15 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 17 Nov 2021 18:02:15 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v4] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> <35nX9qKjYdfHjbhRh1ngW6z4GglHxIgrY5fOfkCjRgY=.38cc2559-872e-4cc6-934f-d353086e2488@github.com> Message-ID: On Wed, 17 Nov 2021 13:26:00 GMT, Mai ??ng Qu?n Anh wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4058: >> >>> 4056: void C2_MacroAssembler::vector_mask_operation(int opc, Register dst, KRegister mask, >>> 4057: int masklen, int masksize, int vec_enc) { >>> 4058: assert(VM_Version::supports_bmi1(), "Strange hardware"); >> >> Also need to check for supports_lzcnt(). > > We have separate checks for all `popcnt`, `lzcnt` and `tzcnt`, do you think the function should verify or just let the assembler throw after? Good to have assert here in this function as well. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From sviswanathan at openjdk.java.net Wed Nov 17 18:41:11 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 17 Nov 2021 18:41:11 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v3] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Tue, 9 Nov 2021 16:30:20 GMT, Mai ??ng Qu?n Anh wrote: >> Mai ??ng Qu?n Anh has updated the pull request incrementally with two additional commits since the last revision: >> >> - support for non-bmi, some refinement >> - restore VectorStoreMaskNode, move logic to backend > > The latest change reverts the change in the mid-end and lets the x86 back-end perform the elision when matching. Some minor changes in the C2_MacroAssembler were made to improve the code emitted by first true operations, as well as to reduce the width of instructions that operate on index calculations from 64 bits to 32 bits. > Thank you very much. @merykitty Please send this PR directly versus the openjdk/jdk mainline. This is a good optimization to have in JDK 18. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From njian at openjdk.java.net Thu Nov 18 01:35:01 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 18 Nov 2021 01:35:01 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v2] In-Reply-To: References: Message-ID: <5-MViRobhSEXQGRqAVLpYvdbwqfrJ-Pdv4REEd1szRw=.7acfd308-79ce-4e06-8db0-6f5b44a13fb0@github.com> > Resolve aarch64 conflicts. Also remove globalDefinitions_vecApi.hpp and it's reference in globalDefinitions.hpp as discussed in the review of https://github.com/openjdk/jdk/pull/5873. Ningsheng Jian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 781 commits: - Merge master into vectorIntrinsics Resolve aarch64 conflicts and also remove globalDefinitions_vecApi.hpp to follow current jdk/master. - Update perf tests. Reviewed-by: sviswanathan - Make method package private. Reviewed-by: sviswanathan - 8275025: Unable to inline vectmask convert Reviewed-by: jbhateja - 8274569: X86 backend related incorrectness issues in legacy store mask patterns Co-authored-by: Jatin Bhateja Co-authored-by: Jie Fu Reviewed-by: sviswanathan - Fix typo in VectorMask.laneIsSet Reviewed-by: sviswanathan - 8274631: assert(false) failed: bad AD file with -XX:UseKNLSetting Reviewed-by: psandoz - Merge panama-vector:master Reviewed-by: sviswanathan, eliu, jbhateja - Merge panama-vector:vectorIntrinsics+mask Reviewed-by: eliu, jbhateja - 8274342: AArch64: [vector] AArch64 SVE backend code cleanup Reviewed-by: njian - ... and 771 more: https://git.openjdk.java.net/panama-vector/compare/a77d8ddf...9937e26d ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/165/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=165&range=01 Stats: 68710 lines in 91 files changed: 68688 ins; 14 del; 8 mod Patch: https://git.openjdk.java.net/panama-vector/pull/165.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/165/head:pull/165 PR: https://git.openjdk.java.net/panama-vector/pull/165 From njian at openjdk.java.net Thu Nov 18 01:35:05 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 18 Nov 2021 01:35:05 GMT Subject: [vectorIntrinsics] Integrated: Merge panama-vector:master In-Reply-To: References: Message-ID: On Wed, 17 Nov 2021 07:36:19 GMT, Ningsheng Jian wrote: > Resolve aarch64 conflicts. Also remove globalDefinitions_vecApi.hpp and it's reference in globalDefinitions.hpp as discussed in the review of https://github.com/openjdk/jdk/pull/5873. This pull request has now been integrated. Changeset: b744b39d Author: Ningsheng Jian URL: https://git.openjdk.java.net/panama-vector/commit/b744b39d42a8fa73b59456d860c117788d442d5c Stats: 909496 lines in 2392 files changed: 469232 ins; 431206 del; 9058 mod Merge panama-vector:master Reviewed-by: sviswanathan ------------- PR: https://git.openjdk.java.net/panama-vector/pull/165 From duke at openjdk.java.net Thu Nov 18 08:13:14 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Thu, 18 Nov 2021 08:13:14 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v3] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Wed, 17 Nov 2021 18:37:20 GMT, Sandhya Viswanathan wrote: >> The latest change reverts the change in the mid-end and lets the x86 back-end perform the elision when matching. Some minor changes in the C2_MacroAssembler were made to improve the code emitted by first true operations, as well as to reduce the width of instructions that operate on index calculations from 64 bits to 32 bits. >> Thank you very much. > > @merykitty Please send this PR directly versus the openjdk/jdk mainline. This is a good optimization to have in JDK 18. @sviswa7 I have addressed your reviews and created a pull request in mainline. May you create an issue for the PR, please. Thank you very much. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Thu Nov 18 14:59:46 2021 From: duke at openjdk.java.net (duke) Date: Thu, 18 Nov 2021 14:59:46 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <27d06aa4-221a-4892-8b59-ae6dd6bf42f5@openjdk.org> Changeset: fb07746a Author: Jorn Vernee Date: 2021-11-18 14:57:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb07746ab9eb121e9b5e9e0d07cf9ad6f5eabc9a 8275647: Enable multi-register return values for optimized upcall stubs Reviewed-by: mcimadamore, ngasson ! src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp ! src/hotspot/cpu/aarch64/foreign_globals_aarch64.hpp ! src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp ! src/hotspot/cpu/arm/foreign_globals_arm.cpp ! src/hotspot/cpu/arm/foreign_globals_arm.hpp ! src/hotspot/cpu/arm/universalUpcallHandle_arm.cpp ! src/hotspot/cpu/ppc/foreign_globals_ppc.cpp ! src/hotspot/cpu/ppc/foreign_globals_ppc.hpp ! src/hotspot/cpu/ppc/universalUpcallHandle_ppc.cpp ! src/hotspot/cpu/s390/foreign_globals_s390.cpp ! src/hotspot/cpu/s390/foreign_globals_s390.hpp ! src/hotspot/cpu/s390/universalUpcallHandle_s390.cpp ! src/hotspot/cpu/x86/foreign_globals_x86.cpp ! src/hotspot/cpu/x86/foreign_globals_x86.hpp ! src/hotspot/cpu/x86/universalUpcallHandler_x86_32.cpp ! src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp ! src/hotspot/cpu/zero/foreign_globals_zero.cpp ! src/hotspot/cpu/zero/foreign_globals_zero.hpp ! src/hotspot/cpu/zero/universalUpcallHandle_zero.cpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/prims/foreign_globals.cpp ! src/hotspot/share/prims/foreign_globals.hpp ! src/hotspot/share/prims/universalUpcallHandler.cpp ! src/hotspot/share/prims/universalUpcallHandler.hpp ! src/hotspot/share/prims/upcallStubs.cpp ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/BufferLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java Changeset: 4882930e Author: duke Date: 2021-11-18 14:58:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4882930e695dff03c843903efa1053130a7d631f Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Thu Nov 18 15:01:14 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 18 Nov 2021 15:01:14 GMT Subject: [foreign-memaccess+abi] Integrated: 8275647: Enable multi-register return values for optimized upcall stubs In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 19:07:45 GMT, Jorn Vernee wrote: > Hi, > > After we've added multi-register return support to native invokers, this patch does the same for optimized upcall stubs. The strategy is very similar: the caller (in this case the upcall stub) allocates a return buffer in which the return values are stored, and then after the upcall shuffles the return values from the buffer into the right registers. > > This patch also removes the buffered invocation strategy for upcalls, and all related code, such as BufferLayout. > > ~Note, in it's current state this patch will disable regress AArch64 since optimized upcalls are not implemented there yet. i.e. this PR is blocked by: https://bugs.openjdk.java.net/browse/JDK-8275646~ > > Jorn This pull request has now been integrated. Changeset: fb07746a Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/fb07746ab9eb121e9b5e9e0d07cf9ad6f5eabc9a Stats: 1167 lines in 32 files changed: 268 ins; 808 del; 91 mod 8275647: Enable multi-register return values for optimized upcall stubs Reviewed-by: mcimadamore, ngasson ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/608 From jvernee at openjdk.java.net Thu Nov 18 16:04:17 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 18 Nov 2021 16:04:17 GMT Subject: [foreign-memaccess+abi] RFR: Add missing include for Linux Message-ID: This PR adds a missing include that is needed on Linux, which didn't show up when compiling under WSL. ------------- Commit messages: - Add missing include for Linux Changes: https://git.openjdk.java.net/panama-foreign/pull/614/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=614&range=00 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/614.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/614/head:pull/614 PR: https://git.openjdk.java.net/panama-foreign/pull/614 From mcimadamore at openjdk.java.net Thu Nov 18 17:04:00 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 18 Nov 2021 17:04:00 GMT Subject: [foreign-memaccess+abi] RFR: Add missing include for Linux In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 15:59:13 GMT, Jorn Vernee wrote: > This PR adds a missing include that is needed on Linux, which didn't show up when compiling under WSL. Strange - I did build and test the changes... ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/614 From duke at openjdk.java.net Thu Nov 18 17:47:04 2021 From: duke at openjdk.java.net (duke) Date: Thu, 18 Nov 2021 17:47:04 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <32fd8c03-bd26-4e0f-b263-686e0fd81757@openjdk.org> Changeset: 68e97308 Author: Jorn Vernee Date: 2021-11-18 17:44:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/68e97308327340b18167def38490f741c2a7d532 Add missing include for Linux Reviewed-by: mcimadamore ! src/hotspot/cpu/x86/foreign_globals_x86.cpp Changeset: a6ca3d80 Author: duke Date: 2021-11-18 17:45:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6ca3d80993a258212945e10dc313a8fa41e39b1 Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Thu Nov 18 17:48:08 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 18 Nov 2021 17:48:08 GMT Subject: [foreign-memaccess+abi] RFR: Add missing include for Linux In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 17:00:45 GMT, Maurizio Cimadamore wrote: > > > Strange - I did build and test the changes... Okay, I think it might be dependent on the compiler version maybe then... ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/614 From jvernee at openjdk.java.net Thu Nov 18 17:48:11 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 18 Nov 2021 17:48:11 GMT Subject: [foreign-memaccess+abi] Integrated: Add missing include for Linux In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 15:59:13 GMT, Jorn Vernee wrote: > This PR adds a missing include that is needed on Linux, which didn't show up when compiling under WSL. This pull request has now been integrated. Changeset: 68e97308 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/68e97308327340b18167def38490f741c2a7d532 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Add missing include for Linux Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/614 From sviswanathan at openjdk.java.net Thu Nov 18 21:25:50 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 18 Nov 2021 21:25:50 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:vectorIntrinsics+compress Message-ID: Merge vectorIntrinsics+compress into vectorIntrinsics. @nsjian need your help to update test/hotspot/gtest/aarch64/asmtest.out.h. Best Regards, Sandhya ------------- Commit messages: - Merge panama-vector:vectorIntrinsics+compress - Compress JavaDoc. - Merge panama-vector:vectorIntrinsics - 8276083: Incremental patch to further optimize new compress/expand APIs over X86 - 8275231: Intrinsify VectorMask.compress API for X86 target. - Merge panama-vector:vectorIntrinsics - 8275255: AArch64: Backend support for compress VectorAPI - 8274975: Add micro benchmark: ALIBABA selective store use case - 8274971: Add VectorMask.compress API - 8274889: Intrinsify Vector.expand/compress APIs for X86 - ... and 4 more: https://git.openjdk.java.net/panama-vector/compare/b744b39d...1b727e29 The webrevs contain the adjustments done while merging with regards to each parent branch: - vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=167&range=00.0 - panama-vector:vectorIntrinsics+compress: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=167&range=00.1 Changes: https://git.openjdk.java.net/panama-vector/pull/167/files Stats: 7218 lines in 140 files changed: 7139 ins; 19 del; 60 mod Patch: https://git.openjdk.java.net/panama-vector/pull/167.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/167/head:pull/167 PR: https://git.openjdk.java.net/panama-vector/pull/167 From sviswanathan at openjdk.java.net Fri Nov 19 00:18:04 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 19 Nov 2021 00:18:04 GMT Subject: [vectorIntrinsics] RFR: Improve mask reduction operations on AVX [v3] In-Reply-To: References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Wed, 17 Nov 2021 18:37:20 GMT, Sandhya Viswanathan wrote: >> The latest change reverts the change in the mid-end and lets the x86 back-end perform the elision when matching. Some minor changes in the C2_MacroAssembler were made to improve the code emitted by first true operations, as well as to reduce the width of instructions that operate on index calculations from 64 bits to 32 bits. >> Thank you very much. > > @merykitty Please send this PR directly versus the openjdk/jdk mainline. This is a good optimization to have in JDK 18. > @sviswa7 I have addressed your reviews and created a pull request in mainline. May you create an issue for the PR, please. Thank you very much. The PR is: https://bugs.openjdk.java.net/browse/JDK-8277426 ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From duke at openjdk.java.net Fri Nov 19 11:06:54 2021 From: duke at openjdk.java.net (duke) Date: Fri, 19 Nov 2021 11:06:54 GMT Subject: git: openjdk/panama-foreign: master: 95 new changesets Message-ID: <9a21673a-3b9e-41c2-b65c-8430c596976c@openjdk.org> Changeset: 13deb384 Author: Julia Boes Date: 2021-11-12 12:05:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13deb38433444a196af5e22e9b29bea6a9a15400 8276848: sun.net.httpserver.simpleserver.CommandLinePositiveTest: test does not specify port Reviewed-by: dfuchs + test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePortNotSpecifiedTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePositiveTest.java Changeset: c4b44329 Author: Magnus Ihse Bursie Date: 2021-11-12 14:08:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c4b44329c1d250f790ca82dd419cdf3330da16f5 8277012: Use blessed modifier order in src/utils Reviewed-by: dholmes, stuefe ! src/utils/IdealGraphVisualizer/Bytecodes/src/main/java/com/sun/hotspot/igv/bytecodes/BytecodeViewTopComponent.java ! src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/ControlFlowTopComponent.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/BinaryParser.java ! src/utils/IdealGraphVisualizer/FilterWindow/src/main/java/com/sun/hotspot/igv/filterwindow/FilterTopComponent.java ! src/utils/IdealGraphVisualizer/Settings/src/main/java/com/sun/hotspot/igv/settings/Settings.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/BasicLogEvent.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogCleanupReader.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java ! src/utils/src/build/tools/commentchecker/CommentChecker.java ! src/utils/src/build/tools/dirdiff/DirDiff.java Changeset: 51a5731d Author: Magnus Ihse Bursie Date: 2021-11-12 14:12:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51a5731d6dc4b6f6feac920a4b8b49c15fd6b34f 8277016: Use blessed modifier order in jdk.httpserver Reviewed-by: dfuchs ! src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/Request.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java Changeset: aeba6530 Author: Andrew Leonard Date: 2021-11-12 14:43:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aeba65303479130d9bab74484accad5d7d116a40 8276743: Make openjdk build Zip Archive generation "reproducible" Reviewed-by: erikj, ihse ! make/Main.gmk ! make/ToolsJdk.gmk ! make/common/ZipArchive.gmk + make/jdk/src/classes/build/tools/makezipreproducible/MakeZipReproducible.java Changeset: 3b2585c0 Author: Coleen Phillimore Date: 2021-11-12 16:17:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3b2585c02bd9d66cc2c8b2d5c16e9a48f4280d07 8276658: Clean up JNI local handles code Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/gc/shared/concurrentGCThread.cpp ! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/jniHandles.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/nonJavaThread.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java Changeset: 5a2452c8 Author: Andrey Turbanov Committer: Daniel Fuchs Date: 2021-11-12 16:30:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5a2452c80e64b8b7a1799caa1a8a6e9e6a7dab6d 8274835: Remove unnecessary castings in java.base Reviewed-by: mullan, naoto, lancea, bpb ! src/java.base/share/classes/java/io/SequenceInputStream.java ! src/java.base/share/classes/java/lang/ClassValue.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/security/Signature.java ! src/java.base/share/classes/java/util/GregorianCalendar.java ! src/java.base/share/classes/java/util/HashSet.java ! src/java.base/share/classes/java/util/stream/ReferencePipeline.java ! src/java.base/share/classes/sun/net/www/MimeTable.java ! src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java ! src/java.base/share/classes/sun/security/provider/DSAPublicKey.java ! src/java.base/share/classes/sun/security/provider/certpath/PKIX.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/util/calendar/Era.java Changeset: 0d2980cd Author: Coleen Phillimore Date: 2021-11-12 17:03:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0d2980cdd1486b0689a71fc107a1d4c100bd3025 8258192: Obsolete the CriticalJNINatives flag Reviewed-by: mdoerr, shade ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/vm_version_arm_32.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/zero/sharedRuntime_zero.cpp ! src/hotspot/cpu/zero/vm_version_zero.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/prims/nativeLookup.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.java - test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/libCNCheckLongArgs.c - test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/LookUp.java - test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/libCNLookUp.c - test/hotspot/jtreg/gc/CriticalNative.java - test/hotspot/jtreg/gc/CriticalNativeArgs.java - test/hotspot/jtreg/gc/libCriticalNative.c - test/hotspot/jtreg/gc/stress/CriticalNativeStress.java Changeset: b85500e5 Author: Lance Andersen Date: 2021-11-12 17:12:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b85500e52479c48b02a96b28fddefa2b25d5d9bd 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File Reviewed-by: redestad, alanb ! src/java.base/share/classes/java/util/zip/ZipFile.java + test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java Changeset: 74f3e69d Author: Daniel D. Daugherty Date: 2021-11-12 18:46:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74f3e69dc888685558408e663df5d32cb906991f 8277071: [BACKOUT] JDK-8276743 Make openjdk build Zip Archive generation "reproducible" Reviewed-by: erikj ! make/Main.gmk ! make/ToolsJdk.gmk ! make/common/ZipArchive.gmk - make/jdk/src/classes/build/tools/makezipreproducible/MakeZipReproducible.java Changeset: 176d21d6 Author: Daniel D. Daugherty Date: 2021-11-12 19:06:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/176d21d6c525f8fd9592db5b4975308ea0001856 8276824: refactor Thread::is_JavaThread_protected Reviewed-by: coleenp, rehn, dholmes ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 8c5f0304 Author: Man Cao Date: 2021-11-12 22:34:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c5f03049196e66a4f8411bdd853b287134e7ce5 8276453: Undefined behavior in C1 LIR_OprDesc causes SEGV in fastdebug build Co-authored-by: Chuck Rasbold Co-authored-by: James Y Knight Reviewed-by: kvn, dlong ! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_FrameMap_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp ! src/hotspot/cpu/arm/c1_FrameMap_arm.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_CodeStubs_ppc.cpp ! src/hotspot/cpu/ppc/c1_FrameMap_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.hpp ! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp ! src/hotspot/cpu/s390/c1_FrameMap_s390.cpp ! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp ! src/hotspot/cpu/x86/c1_FrameMap_x86.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.hpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_FrameMap.hpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/barrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.hpp Changeset: 296780c7 Author: Thomas Stuefe Date: 2021-11-15 06:47:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/296780c7ae5c129d24997007600f428b697d3365 8276983: Small fixes to DumpAllocStat::print_stats Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/dumpAllocStats.cpp Changeset: ca2efb73 Author: Richard Reingruber Date: 2021-11-15 07:02:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ca2efb73f59112d9be2ec29db405deb4c58dd435 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend Reviewed-by: cjplummer, sspitsyn, rschmelter ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c + test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java Changeset: b231f5ba Author: Hamlin Li Date: 2021-11-15 10:08:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b231f5baa94c7104324cd206c1081b35fd27164c 8276921: G1: Remove redundant failed evacuation regions calculation in RemoveSelfForwardPtrHRClosure Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: fdcd16a3 Author: Pavel Rappo Date: 2021-11-15 11:25:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fdcd16a38fb9a14a819d68682f9666ebfe7285db 8277048: Tiny improvements to the specification text for java.util.Properties.load Reviewed-by: rriggs, iris, naoto ! src/java.base/share/classes/java/util/Properties.java Changeset: 02f79008 Author: Albert Mingkun Yang Date: 2021-11-15 12:46:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/02f79008828b3dcce3bd6492efaa43e99376c0c5 8276932: G1: Annotate methods with override explicitly in g1CollectedHeap.hpp Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 35a831d5 Author: Thomas Schatzl Date: 2021-11-15 14:34:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35a831d5a755de8f3c71653bd0a37190adddb8ae 8272170: Missing memory barrier when checking active state for regions Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CommittedRegionMap.inline.hpp Changeset: 7fc344dc Author: Hannes Walln?fer Date: 2021-11-15 15:53:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fc344dc96008f277dacf5518b28447f3a598cde 8277028: Use service type documentation as fallback for @provides Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServices.java Changeset: 9046077f Author: Alexey Semenyuk Date: 2021-11-15 17:57:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9046077fe6ce7bb042fbd0fa1a80537cb4a60581 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional Reviewed-by: almatvee, herrick ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.control ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java ! test/jdk/tools/jpackage/linux/LinuxResourceTest.java ! test/jdk/tools/jpackage/linux/ReleaseTest.java Changeset: fe45835f Author: Alexey Semenyuk Date: 2021-11-15 17:57:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe45835f7cebfccd4544ae19d88bdc7f07560fbe 8274856: Failing jpackage tests with fastdebug/release build Reviewed-by: almatvee, herrick ! src/jdk.jpackage/linux/native/applauncher/LinuxLauncher.c ! src/jdk.jpackage/linux/native/libapplauncher/LinuxLauncherLib.cpp ! src/jdk.jpackage/share/native/applauncher/AppLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.h ! src/jdk.jpackage/share/native/applauncher/JvmLauncherLib.c ! src/jdk.jpackage/unix/native/common/UnixSysInfo.cpp ! src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp Changeset: 1830b8da Author: Thomas Schatzl Date: 2021-11-15 18:09:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1830b8da9028af430ee4791f310b5fc9cb1ff37d 8275056: Virtualize G1CardSet containers over heap region Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/g1CardSet.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1_globals.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegionBounds.hpp ! src/hotspot/share/gc/g1/heapRegionBounds.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/jtreg/gc/arguments/TestG1HeapRegionSize.java Changeset: db0c8d52 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-15 19:14:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db0c8d522704d2e12bce4ebeb9297b57e3789f4f 8274232: Cleanup unnecessary null comparison before instanceof check in jdk.jdi Reviewed-by: cjplummer, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ByteValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/FieldImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LocalVariableImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/StackFrameImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VoidValueImpl.java Changeset: 7a870418 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-15 19:18:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a870418a3e8de3b290ba71cbe4ca7979ec029f9 8275385: Change nested classes in jdk.jdi to static nested classes Reviewed-by: sspitsyn, amenkov, cjplummer ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SDE.java Changeset: 9326eb14 Author: Dean Long Date: 2021-11-15 21:09:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9326eb14617bf08e3376f854fc022e11d1ef34dd 8276095: ciReplay: replay failure due to incomplete ciMethodData information Reviewed-by: chagedorn, kvn ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/ci/ciMethodData.hpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciReplay.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciMethodData.java ! test/hotspot/jtreg/compiler/ciReplay/TestLambdas.java Changeset: a59c9b2a Author: Paul Sandoz Date: 2021-11-15 21:48:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a59c9b2ac277d6ff6be1700d91ff389f137e61ca 8271515: Integration of JEP 417: Vector API (Third Incubator) Co-authored-by: Sandhya Viswanathan Co-authored-by: Jatin Bhateja Co-authored-by: Ningsheng Jian Co-authored-by: Xiaohong Gong Co-authored-by: Eric Liu Co-authored-by: Jie Fu Co-authored-by: Vladimir Ivanov Co-authored-by: John R Rose Co-authored-by: Paul Sandoz Co-authored-by: Rado Smogura Reviewed-by: kvn, sviswanathan, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.cpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/forms.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/chaitin.cpp ! src/hotspot/share/opto/chaitin.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/matcher.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/postaloc.cpp ! src/hotspot/share/opto/regmask.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! src/hotspot/share/opto/vector.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! src/hotspot/share/prims/vectorSupport.cpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/growableArray.hpp ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template ! src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h + test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastTest.java + test/hotspot/jtreg/compiler/vectorapi/VectorMaskLoadStoreTest.java + test/hotspot/jtreg/compiler/vectorapi/VectorMemoryAlias.java Changeset: bd92674b Author: Calvin Cheung Date: 2021-11-16 02:34:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd92674be563ad291990216b7cdf061c498f5dd3 8276184: Exclude lambda proxy class from the CDS archive if its caller class is excluded Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! test/hotspot/jtreg/runtime/cds/appcds/LambdaContainsOldInf.java ! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaContainsOldInf.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaForOldInfInBaseArchive.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/OldClassInBaseArchive.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/RedefineCallerClassTest.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/RedefineCallerClass.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/Hello.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaContainsOldInfApp.java Changeset: e4362007 Author: Aleksey Shipilev Date: 2021-11-16 07:32:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4362007da8e40c076493364df91cf85960a03e7 8008243: Zero: Implement fast bytecodes Reviewed-by: rkennke, coleenp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.hpp ! src/hotspot/share/prims/jvmtiManageCapabilities.cpp Changeset: 7719a74c Author: Thomas Stuefe Date: 2021-11-16 07:49:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7719a74cec8c47fd036226b520a5fce7887386da 8277172: Remove stray comment mentioning instr_size_for_decode_klass_not_null on x64 Reviewed-by: dholmes ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: 1d79cfd3 Author: Stefan Johansson Date: 2021-11-16 08:27:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d79cfd3a16a71ec1bf93a0748e806b21a717b52 8276229: Stop allowing implicit updates in G1BlockOffsetTable Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: b8d33a2a Author: Thomas Stuefe Date: 2021-11-16 09:49:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b8d33a2a4e4ac1be322644102e8f09ce1435b4fb 8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/include/jmm.h ! src/hotspot/share/services/management.cpp ! src/jdk.management/share/native/libmanagement_ext/DiagnosticCommandImpl.c Changeset: 20f3872d Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:13:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/20f3872d1cd6257ab9c76bb998f8dc2d07bc1724 8274261: Use enhanced-for instead of plain 'for' in jdk.jcmd Reviewed-by: sspitsyn, cjplummer ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/ColumnFormat.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/OptionFormat.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/RawOutputFormatter.java Changeset: a9cb8bdb Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:14:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9cb8bdbaac7241959805c491b6d13b6e14f8966 8274168: Avoid String.compareTo == 0 to check String equality in java.management Reviewed-by: sspitsyn, dfuchs, cjplummer, dholmes ! src/java.management/share/classes/javax/management/BinaryRelQueryExp.java ! src/java.management/share/classes/javax/management/loading/MLet.java Changeset: 0bc26837 Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:15:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0bc268377ed5d2dd15bdd7283a77b59ad505e2b7 8274190: Use String.equals instead of String.compareTo in jdk.internal.jvmstat Reviewed-by: cjplummer, sspitsyn ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java Changeset: 9629627e Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:17:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9629627e2c8021c254517ac5463cc66723175fd9 8274163: Use String.equals instead of String.compareTo in jdk.jcmd Reviewed-by: cjplummer, amenkov, sspitsyn ! src/jdk.jcmd/share/classes/sun/tools/jps/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/OptionLister.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java Changeset: c06df25a Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:18:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c06df25a4fb76ee65d3fa99ec0579ca4a406c345 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent Reviewed-by: amenkov, cjplummer, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/DeadlockDetector.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/FindInHeapPanel.java Changeset: 1c45c8a0 Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:19:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c45c8a08287e2d8d7574eaa773850b7f0b33207 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module Reviewed-by: dfuchs, sspitsyn ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java ! src/java.management/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java Changeset: 7906eb05 Author: Hamlin Li Date: 2021-11-16 11:37:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7906eb050d4675092536048e8e21334767e397e6 8277119: Add asserts in GenericTaskQueueSet methods Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/taskqueue.hpp ! src/hotspot/share/gc/shared/taskqueue.inline.hpp Changeset: 9a9a157a Author: Jayathirth D V Date: 2021-11-16 13:18:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9a9a157a7d45cbfb016d4427931e1d5345210f7a 8276905: Use appropriate macosx_version_minimum value while compiling metal shaders Reviewed-by: ihse, kcr, erikj, prr ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: f3eb5014 Author: MeryKitty Committer: Tobias Hartmann Date: 2021-11-16 14:09:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f3eb5014aa75af4463308f52f2bc6e9fcd2da36c 8276162: Optimise unsigned comparison pattern Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/subnode.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestUnsignedComparison.java + test/micro/org/openjdk/bench/vm/compiler/UnsignedComparison.java Changeset: d5e47d6b Author: Yasumasa Suenaga Date: 2021-11-16 14:47:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5e47d6b84514edde23a8baff8c2274e5b3ca6bb 8277089: Use system binutils to build hsdis Reviewed-by: ihse ! make/autoconf/jdk-options.m4 ! src/utils/hsdis/README ! src/utils/hsdis/hsdis.c Changeset: e5ffdf91 Author: Dean Long Date: 2021-11-16 17:25:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e5ffdf9120c14b38e4c8794888d2002e2686ebfc 8276231: ciReplay: SIGSEGV when replay compiling lambdas Reviewed-by: iveresov, chagedorn ! src/hotspot/share/ci/ciReplay.cpp Changeset: b0a463fa Author: Alexander Zuev Date: 2021-11-16 19:01:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b0a463fa59a1c3c554f48267525729bf89a2c5be 8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes! Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java Changeset: cddc6ce4 Author: Daniel Jelinski Committer: Xue-Lei Andrew Fan Date: 2021-11-16 20:34:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cddc6ce44695cba4614c3405eb2b194d7c76489b 8275811: Incorrect instance to dispose Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/InputRecord.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java Changeset: 8ed384cf Author: Roger Riggs Date: 2021-11-16 20:53:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8ed384cfb655d97ba452033e06d18ca38e5fc9b0 8276609: Document setting property `jdk.serialFilter` to an invalid value throws `ExceptionInInitializerError` Reviewed-by: dfuchs, lancea ! src/java.base/share/classes/java/io/ObjectInputFilter.java Changeset: a77d8ddf Author: Ioi Lam Date: 2021-11-16 21:03:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a77d8ddf11fba33007a4f5c0468d69de23f10f6a 8276787: Improve warning messages for -XX:+RecordDynamicDumpInfo Reviewed-by: ccheung, stuefe ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/dynamicArchive.hpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/thread.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 23e5117a Author: Jaikiran Pai Date: 2021-11-17 03:20:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23e5117a55b3f3d0e3d26bf2d481f4ad1c99af57 8276559: (httpclient) Consider adding an HttpRequest.Builder.HEAD method to build a HEAD request. Reviewed-by: cstein, dfuchs ! src/java.net.http/share/classes/java/net/http/HttpRequest.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpRequestBuilderImpl.java ! test/jdk/java/net/httpclient/HeadTest.java ! test/jdk/java/net/httpclient/HttpRequestBuilderTest.java ! test/jdk/java/net/httpclient/HttpRequestNewBuilderTest.java ! test/jdk/java/net/httpclient/RequestBuilderTest.java Changeset: 08f65a59 Author: Fairoz Matte Committer: Jayathirth D V Date: 2021-11-17 06:13:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/08f65a59a7bd387974d94253ec7093524a3e92f1 8277313: Validate header failed for test/jdk/java/net/httpclient/HeadTest.java Reviewed-by: jdv ! test/jdk/java/net/httpclient/HeadTest.java Changeset: 9aa30de4 Author: Faye Gao Committer: Tobias Hartmann Date: 2021-11-17 08:19:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9aa30de4bb55357ddf0900e6103062f02e85753b 8275317: AArch64: Support some type conversion vectorization in SLP Reviewed-by: thartmann, ngasson ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/vectornode.cpp ! test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java ! test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java ! test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java Changeset: e9934e12 Author: Albert Mingkun Yang Date: 2021-11-17 09:59:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e9934e1243929514e147ecdd3cefa74168ed0500 8277221: G1: Remove methods without implementations in G1CollectedHeap Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 2af9e597 Author: Kevin Walls Date: 2021-11-17 11:59:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2af9e5976fdf94afc7dbe5ad7827553818057bae 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test Reviewed-by: jiefu, sspitsyn ! test/jdk/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java ! test/jdk/sun/jvmstat/monitor/HostIdentifier/testcases - test/jdk/sun/tools/jps/TestJpsHostName.java Changeset: 9f2f46ee Author: Harold Seigel Date: 2021-11-17 14:25:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f2f46ee4576d9cd0190530949e5e50f796a6bdc 8275037: Test vmTestbase/nsk/sysdict/vm/stress/btree/btree011/btree011.java crashes with memory exhaustion on Windows Reviewed-by: coleenp ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/GenClassesBuilder.java ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/SysDictTest.java Changeset: 8f5a8f74 Author: Alexander Zuev Date: 2021-11-17 17:36:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8f5a8f740b62c27cc244debe57aaa2975f84a694 8264293: Create implementation for NSAccessibilityMenu protocol peer 8264296: Create implementation for NSAccessibilityPopUpButton protocol peer 8264295: Create implementation for NSAccessibilityMenuItem protocol peer 8264294: Create implementation for NSAccessibilityMenuBar protocol peer Reviewed-by: pbansal, ant ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuBarAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuBarAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuItemAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuItemAccessibility.m Changeset: b6876649 Author: Alex Kasko Committer: Zhengyu Gu Date: 2021-11-17 17:48:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6876649a82bed508d817ccbde1600d00937e4b2 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points Reviewed-by: bpb, shade ! test/jdk/java/nio/file/FileStore/Basic.java Changeset: a907b2b1 Author: Coleen Phillimore Date: 2021-11-17 19:53:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a907b2b144f2af27392eb7c2f9656fbb1a759618 8276177: nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption failed with "assert(def_ik->is_being_redefined()) failed: should be being redefined to get here" Reviewed-by: hseigel, sspitsyn ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/utilities/accessFlags.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 262d0700 Author: Weijun Wang Date: 2021-11-17 20:03:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/262d07001babcbe7f9acd2053aa3b7bac304cf85 8277246: Check for NonRepudiation as well when validating a TSA certificate Reviewed-by: xuelei, mullan ! src/java.base/share/classes/sun/security/validator/EndEntityChecker.java ! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java Changeset: 8881f29b Author: Dean Long Date: 2021-11-17 20:18:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8881f29bc83336bcbc0e8ff0cf1d2bbe55172f5c 8277310: ciReplay: @cpi MethodHandle references not resolved Reviewed-by: chagedorn, thartmann ! src/hotspot/share/ci/ciReplay.cpp Changeset: 007ad7c7 Author: Joe Darcy Date: 2021-11-17 20:23:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/007ad7c77c6277ce733386b4402b787d81dd41cf 8277303: Terminology mismatch between JLS17-3.9 and SE17's javax.lang.model.SourceVersion method specs Reviewed-by: iris, jjg ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Changeset: d8c02802 Author: Dean Long Date: 2021-11-17 20:26:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8c0280273fa9f8e113088d6a43a4af076cd4f87 8277316: ciReplay: dump_replay_data is not thread-safe Reviewed-by: chagedorn, thartmann ! src/hotspot/share/ci/ciEnv.cpp Changeset: 6bb04626 Author: Sean Coffey Date: 2021-11-17 20:50:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6bb04626af6574ef1e8d4b7dad0389d4b59f5d08 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE Reviewed-by: weijun ! src/java.base/share/classes/sun/security/pkcs/PKCS9Attributes.java ! test/jdk/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 45a60db5 Author: Albert Mingkun Yang Date: 2021-11-17 21:02:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/45a60db5a0aa78fa9eb1c2899bd167c136e0fa03 8277045: G1: Remove unnecessary set_concurrency call in G1ConcurrentMark::weak_refs_work Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp Changeset: ce4471f8 Author: Daniel D. Daugherty Date: 2021-11-17 21:23:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce4471f806e51bc9f9ad746b69ba490443947110 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 8277351: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on macosx-x64 Reviewed-by: tschatzl, bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: 29e552c0 Author: Sergey Bylokhov Date: 2021-11-17 22:21:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/29e552c03a2825f9526330072668a1d63ac68fd4 8272358: Some tests may fail when executed with other locales than the US Reviewed-by: aivanov ! test/langtools/jdk/jshell/ToolBasicTest.java ! test/langtools/jdk/jshell/ToolSimpleTest.java ! test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java ! test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java Changeset: 231fb61a Author: Naoto Sato Date: 2021-11-18 01:12:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/231fb61aaeae04787c06a4c972197943d9085627 8276970: Default charset for PrintWriter that wraps PrintStream Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java + test/jdk/java/io/PrintStream/InheritEncodingTest.java Changeset: b8453ebd Author: Naoto Sato Date: 2021-11-18 01:13:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b8453ebdb471e08cc8d62c777f33ad52902f67d7 8275007: Java fails to start with null charset if LC_ALL is set to certain locales Reviewed-by: rriggs, iris, joehw, alanb ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/native/libjava/jni_util.c Changeset: 81938001 Author: Fei Gao Committer: Ningsheng Jian Date: 2021-11-18 02:41:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81938001f9bae56c59f4e18b7756089f2cf0bf74 8274179: AArch64: Support SVE operations with encodable immediates Reviewed-by: aph, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.cpp ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h ! test/hotspot/jtreg/compiler/codegen/TestByteVect.java ! test/hotspot/jtreg/compiler/codegen/TestCharVect.java ! test/hotspot/jtreg/compiler/codegen/TestIntVect.java ! test/hotspot/jtreg/compiler/codegen/TestLongVect.java ! test/hotspot/jtreg/compiler/codegen/TestShortVect.java Changeset: 91607436 Author: Prasanta Sadhukhan Date: 2021-11-18 04:33:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/91607436b79126ccb999deaf38a98209dbfe6ec1 8276058: Some swing test fails on specific CI macos system Reviewed-by: prr, kizune ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java ! test/jdk/javax/swing/JButton/8151303/PressedIconTest.java ! test/jdk/javax/swing/JInternalFrame/8069348/bug8069348.java ! test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java Changeset: 2f4b5405 Author: Doug Simon Date: 2021-11-18 08:32:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f4b5405f0b53782f3ed5274f68b31eb968efb6d 8276314: [JVMCI] check alignment of call displacement during code installation Reviewed-by: kvn ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp Changeset: db55f927 Author: Ioi Lam Date: 2021-11-18 08:49:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db55f9272c0889f4ea4dee0f4aa3d9613fadb2f8 8277343: dynamicArchive/SharedArchiveFileOption.java failed: '-XX:+RecordDynamicDumpInfo is unsupported when a dynamic CDS archive is specified in -XX:SharedArchiveFile:' missing Reviewed-by: hseigel, ccheung ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicArchiveTestBase.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java Changeset: 0a65e8b2 Author: Andrey Turbanov Committer: Alexey Ivanov Date: 2021-11-18 10:48:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0a65e8b282fd41e57108422fbd140527d9697efd 8276794: Change nested classes in java.desktop to static nested classes Reviewed-by: serb, aivanov ! src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/DHTMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/DQTMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/SOSMarkerSegment.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopPaneUI.java ! src/java.desktop/share/classes/com/sun/media/sound/EventDispatcher.java ! src/java.desktop/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java ! src/java.desktop/share/classes/com/sun/media/sound/SunFileWriter.java ! src/java.desktop/share/classes/java/awt/CardLayout.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Polygon.java ! src/java.desktop/share/classes/java/awt/ScrollPane.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/print/Book.java ! src/java.desktop/share/classes/java/beans/XMLEncoder.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioInputStream.java ! src/java.desktop/share/classes/javax/swing/GroupLayout.java ! src/java.desktop/share/classes/javax/swing/JComboBox.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/KeyboardManager.java ! src/java.desktop/share/classes/javax/swing/RepaintManager.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/java.desktop/share/classes/javax/swing/text/DefaultHighlighter.java ! src/java.desktop/share/classes/javax/swing/text/ElementIterator.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/StringContent.java ! src/java.desktop/share/classes/javax/swing/text/StyleContext.java ! src/java.desktop/share/classes/javax/swing/text/html/ImageView.java ! src/java.desktop/share/classes/javax/swing/text/html/TableView.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFReader.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/java.desktop/share/classes/sun/awt/PlatformFont.java ! src/java.desktop/share/classes/sun/java2d/loops/RenderCache.java ! src/java.desktop/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/GeneralCompositePipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/SpanClipRenderer.java ! src/java.desktop/share/classes/sun/print/PrintJob2D.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/java.desktop/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextFieldPeer.java ! src/java.desktop/unix/classes/sun/font/X11GB2312.java ! src/java.desktop/unix/classes/sun/font/X11GBK.java ! src/java.desktop/unix/classes/sun/font/X11KSC5601.java ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java ! src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DRenderer.java Changeset: 77cc5088 Author: Albert Mingkun Yang Date: 2021-11-18 10:52:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77cc508802899b370f1cdf592331f81efb8d9208 8277215: Remove redundancy in ReferenceProcessor constructor args Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 2c06bca9 Author: Erik ?sterlund Date: 2021-11-18 11:17:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2c06bca98fcf9d129d6085e26c225fb26368a558 8266368: Inaccurate after_unwind hook in C2 exception handler Reviewed-by: dlong, thartmann ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: 38345bd2 Author: Evgeny Astigeevich Committer: Volker Simonis Date: 2021-11-18 11:18:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38345bd28db83371676f1685806ddc207a833879 8277137: Set OnSpinWaitInst/OnSpinWaitInstCount defaults to "isb"/1 for Arm Neoverse N1 Reviewed-by: phh, aph, ngasson ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java Changeset: b3a62b48 Author: Harold Seigel Date: 2021-11-18 13:18:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b3a62b48816358ac7dadde4e7893190500ca7b79 8276795: Deprecate seldom used CDS flags Reviewed-by: dholmes, ccheung, iklam ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/intrinsics/klass/TestIsPrimitive.java ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: a44b45fd Author: Sean Mullan Date: 2021-11-18 13:48:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a44b45fdf31275a2c1e9d1d0132874a7de45f8ee 4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath Reviewed-by: valeriep, rriggs ! src/java.base/share/classes/java/security/cert/CertPath.java ! src/java.base/share/classes/java/security/cert/Certificate.java Changeset: 00c388b4 Author: Erik ?sterlund Date: 2021-11-18 14:32:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00c388b4aba41d5f0874585e9c0a33c4571805f6 8259643: ZGC can return metaspace OOM prematurely Reviewed-by: stefank, pliden, stuefe ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/memory/metaspace.cpp + src/hotspot/share/memory/metaspaceCriticalAllocation.cpp + src/hotspot/share/memory/metaspaceCriticalAllocation.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: d93b238f Author: Erik ?sterlund Date: 2021-11-18 14:44:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d93b238f9725727ae1e2e9f203943b5ddf778f35 8277180: Intrinsify recursive ObjectMonitor locking for C2 x64 and A64 Reviewed-by: aph, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp Changeset: 276bfcd1 Author: Prasanta Sadhukhan Date: 2021-11-18 15:17:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/276bfcd1a115f90dde644abef79d64bb61788c75 8277407: javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java fails to compile after JDK-8276058 Reviewed-by: dcubed ! test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java Changeset: 354a34ea Author: Albert Mingkun Yang Date: 2021-11-18 15:54:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/354a34ea2077c9372e585adb1303df604827a2e2 8277336: Improve CollectedHeap::safepoint_workers comments Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/shared/collectedHeap.hpp Changeset: 5d249c46 Author: Alexander Zuev Date: 2021-11-18 16:07:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5d249c46abc8dfdc3acdaff41d26f3bd9ba84731 8275071: [macos] A11y cursor gets stuck when combobox is closed Reviewed-by: serb, pbansal ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java Changeset: ce0f00f6 Author: Thomas Schatzl Date: 2021-11-18 16:59:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce0f00f66e78a504d5e40a25fa213325ec0af394 8276093: Improve naming in closures to iterate over card sets Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/g1CardSet.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp Changeset: 03473b4c Author: Sergey Bylokhov Date: 2021-11-18 18:25:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/03473b4c271b2ec7f0ebdb0edabadf7f36816b9d 8270874: JFrame paint artifacts when dragged from standard monitor to HiDPI monitor Reviewed-by: jdv ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp ! test/jdk/java/awt/Window/WindowResizingOnDPIChanging/WindowResizingOnMovingToAnotherDisplay.java Changeset: 8db0c361 Author: Daniel D. Daugherty Date: 2021-11-18 18:40:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8db0c361a39cf10d373c3d2dfa54267cf53452db 8277414: ProblemList runtime/CommandLine/VMDeprecatedOptions.java on windows-x64 Reviewed-by: mikael, iklam ! test/hotspot/jtreg/ProblemList.txt Changeset: 57eb8647 Author: Niklas Radomski Committer: Martin Doerr Date: 2021-11-18 19:00:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/57eb864765f38185f8db8f1d37681d6cfe2a3c73 8276927: [PPC64] Port shenandoahgc to linux on ppc64le Reviewed-by: rkennke, ihse, mdoerr ! make/autoconf/jvm-features.m4 ! make/hotspot/gensrc/GensrcAdlc.gmk ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.hpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoah_ppc.ad ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Changeset: 36bd4a35 Author: Harold Seigel Date: 2021-11-18 20:06:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36bd4a35fbee077c00c1f4240f1f02f4d7d5f656 8277404: Test VMDeprecatedOptions.java failing with Unable to create shared archive file Reviewed-by: dcubed ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 89b125f4 Author: Roman Kennke Date: 2021-11-18 21:32:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/89b125f4d4d6a467185b4b39861fd530a738e67f 8275527: Refactor forward pointer access Reviewed-by: tschatzl, stefank ! src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/oops/oop.inline.hpp Changeset: 839033ba Author: Man Cao Date: 2021-11-18 23:35:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/839033baf61ca7f10437e8e53b2114b081d97ea9 8276976: Rename LIR_OprDesc to LIR_Opr Co-authored-by: Chuck Rasbold Reviewed-by: thartmann, iveresov ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIR_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_LIR_arm.cpp ! src/hotspot/cpu/ppc/c1_LIR_ppc.cpp ! src/hotspot/cpu/s390/c1_LIR_s390.cpp ! src/hotspot/cpu/x86/c1_LIR_x86.cpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/c1/c1_LinearScan.cpp ! src/hotspot/share/c1/c1_LinearScan.hpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp Changeset: 2f0bde1a Author: Yi Yang Date: 2021-11-19 02:04:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f0bde1a658b0910304c110920a2e8ccbe4557f8 8277102: Dubious PrintCompilation output Reviewed-by: thartmann, dnsimon ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compileTask.hpp ! test/hotspot/jtreg/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java Changeset: 47564cae Author: Tobias Hartmann Date: 2021-11-19 07:07:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47564caeb0628e5c03a0e7f04093adce77d6dd3b 8275643: C2's unaryOp vector intrinsic does not properly handle LongVector.neg Reviewed-by: chagedorn, sviswanathan ! src/hotspot/share/prims/vectorSupport.cpp + test/hotspot/jtreg/compiler/vectorapi/TestLongVectorNeg.java Changeset: f34f1190 Author: Tobias Hartmann Date: 2021-11-19 07:13:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f34f119080b4e8baf396fb26c21d572dd432fd91 8277213: CompileTask_lock is acquired out of order with MethodCompileQueue_lock Reviewed-by: rbackman, coleenp ! src/hotspot/share/compiler/compileTask.hpp Changeset: 2f20b0d8 Author: Jan Lahoda Date: 2021-11-19 07:49:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f20b0d8daca6bdc53b4b9e1837c428930d34236 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/jdk/jshell/ErrorRecoveryTest.java + test/langtools/tools/javac/attr/AttrRecoveryTest.java Changeset: 3a76d397 Author: Tobias Hartmann Date: 2021-11-19 08:23:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3a76d397949ad22e4786476e583cc9d33c015214 8277324: C2 compilation fails with "bad AD file" on x86-32 after JDK-8276162 due to missing match rule Reviewed-by: chagedorn, roland ! src/hotspot/cpu/x86/x86_32.ad Changeset: 7a046e0f Author: Albert Mingkun Yang Date: 2021-11-19 08:31:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a046e0f765e0ad04fd52c9a882c5d90b085bc00 8277371: Remove unnecessary DefNewGeneration::ref_processor_init() Reviewed-by: stefank, tschatzl, mli ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/shared/generation.hpp Changeset: 11d819d6 Author: Hamlin Li Date: 2021-11-19 10:15:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11d819d68a3ce2ae0973b496141c52aa419f90f0 8277439: G1: Correct include guard name in G1EvacFailureObjectsSet.hpp Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp Changeset: b15e6f07 Author: Jie Fu Date: 2021-11-19 10:38:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b15e6f076afe5ac68e9af68756860d0b25adea4b 8277449: compiler/vectorapi/TestLongVectorNeg.java fails with release VMs Reviewed-by: thartmann, chagedorn ! test/hotspot/jtreg/compiler/vectorapi/TestLongVectorNeg.java Changeset: 21d73270 Author: duke Date: 2021-11-19 11:00:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/21d732703b56f481fd3bed35881dfa5efbe29cdf Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Nov 19 11:08:26 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 19 Nov 2021 11:08:26 GMT Subject: [foreign-memaccess+abi] RFR: Merge master Message-ID: <-ZPWEW8wfrj1YeD4GNrQheqmOk3uNF6QreBJamMcI08=.0640a4f3-7405-4f07-98b4-44e3fb3a9d3c@github.com> Hi all, this is an _automatically_ generated pull request to notify you that there are 95 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: The following file contains merge conflicts: - src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. # Ensure target branch is up to date $ git checkout foreign-memaccess+abi $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi # Fetch and checkout the branch for this pull request $ git fetch https://github.com/openjdk-bot/panama-foreign.git +106:openjdk-bot-106 $ git checkout openjdk-bot-106 # Merge the target branch $ git merge foreign-memaccess+abi When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: $ git add paths/to/files/with/conflicts $ git commit -m 'Merge master' When you have created the merge commit, run the following command to push the merge commit to this pull request: $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-106:106 _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. Thanks, J. Duke ------------- Commit messages: - Automatic merge of jdk:master into master - 8277449: compiler/vectorapi/TestLongVectorNeg.java fails with release VMs - 8277439: G1: Correct include guard name in G1EvacFailureObjectsSet.hpp - 8277371: Remove unnecessary DefNewGeneration::ref_processor_init() - 8277324: C2 compilation fails with "bad AD file" on x86-32 after JDK-8276162 due to missing match rule - 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" - 8277213: CompileTask_lock is acquired out of order with MethodCompileQueue_lock - 8275643: C2's unaryOp vector intrinsic does not properly handle LongVector.neg - 8277102: Dubious PrintCompilation output - 8276976: Rename LIR_OprDesc to LIR_Opr - ... and 85 more: https://git.openjdk.java.net/panama-foreign/compare/4ae4c4ca...21d73270 The webrev contains the conflicts with foreign-memaccess+abi: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=615&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/615/files Stats: 34811 lines in 553 files changed: 24287 ins; 5011 del; 5513 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/615.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/615/head:pull/615 PR: https://git.openjdk.java.net/panama-foreign/pull/615 From duke at openjdk.java.net Fri Nov 19 15:04:57 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 19 Nov 2021 15:04:57 GMT Subject: [foreign-memaccess+abi] RFR: Merge master [v2] In-Reply-To: <-ZPWEW8wfrj1YeD4GNrQheqmOk3uNF6QreBJamMcI08=.0640a4f3-7405-4f07-98b4-44e3fb3a9d3c@github.com> References: <-ZPWEW8wfrj1YeD4GNrQheqmOk3uNF6QreBJamMcI08=.0640a4f3-7405-4f07-98b4-44e3fb3a9d3c@github.com> Message-ID: <8lTNoL4dF7yQlYyUwGeyKHAEctXhPa9s0ex0zUjkTl0=.93bb4dcf-6acf-452f-bc30-500c4691505b@github.com> > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 95 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following file contains merge conflicts: > > - src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-memaccess+abi > $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +106:openjdk-bot-106 > $ git checkout openjdk-bot-106 > > # Merge the target branch > $ git merge foreign-memaccess+abi > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-106:106 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke J. Duke 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 850 additional commits since the last revision: - Merge branch 'foreign-memaccess+abi' into 106 - Add missing include for Linux Reviewed-by: mcimadamore - 8275647: Enable multi-register return values for optimized upcall stubs Reviewed-by: mcimadamore, ngasson - 8276987: Optimized upcall stub should be printed with -XX:+PrintStubCode Reviewed-by: jvernee - Merge master - 8275646: Implement optimized upcall stubs on AArch64 Reviewed-by: jvernee - Automatic merge of master into foreign-memaccess+abi - 8255903: Enable multi-register return values for native invokers Reviewed-by: mcimadamore - Merge master - Automatic merge of master into foreign-memaccess+abi - ... and 840 more: https://git.openjdk.java.net/panama-foreign/compare/21d73270...56259eb9 ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/615/files - new: https://git.openjdk.java.net/panama-foreign/pull/615/files/21d73270..56259eb9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=615&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=615&range=00-01 Stats: 43671 lines in 280 files changed: 33205 ins; 7194 del; 3272 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/615.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/615/head:pull/615 PR: https://git.openjdk.java.net/panama-foreign/pull/615 From duke at openjdk.java.net Fri Nov 19 15:04:59 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 19 Nov 2021 15:04:59 GMT Subject: [foreign-memaccess+abi] Integrated: Merge master In-Reply-To: <-ZPWEW8wfrj1YeD4GNrQheqmOk3uNF6QreBJamMcI08=.0640a4f3-7405-4f07-98b4-44e3fb3a9d3c@github.com> References: <-ZPWEW8wfrj1YeD4GNrQheqmOk3uNF6QreBJamMcI08=.0640a4f3-7405-4f07-98b4-44e3fb3a9d3c@github.com> Message-ID: On Fri, 19 Nov 2021 11:00:55 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 95 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > The following file contains merge conflicts: > > - src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-memaccess+abi > $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +106:openjdk-bot-106 > $ git checkout openjdk-bot-106 > > # Merge the target branch > $ git merge foreign-memaccess+abi > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-106:106 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke This pull request has now been integrated. Changeset: e47a8d69 Author: J. Duke Committer: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/e47a8d6995a9119b5bd65a6e1d329a4bf80f58e1 Stats: 34810 lines in 553 files changed: 24287 ins; 5010 del; 5513 mod Merge master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/615 From duke at openjdk.java.net Fri Nov 19 15:11:06 2021 From: duke at openjdk.java.net (duke) Date: Fri, 19 Nov 2021 15:11:06 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 97 new changesets Message-ID: Changeset: 13deb384 Author: Julia Boes Date: 2021-11-12 12:05:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13deb38433444a196af5e22e9b29bea6a9a15400 8276848: sun.net.httpserver.simpleserver.CommandLinePositiveTest: test does not specify port Reviewed-by: dfuchs + test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePortNotSpecifiedTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePositiveTest.java Changeset: c4b44329 Author: Magnus Ihse Bursie Date: 2021-11-12 14:08:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c4b44329c1d250f790ca82dd419cdf3330da16f5 8277012: Use blessed modifier order in src/utils Reviewed-by: dholmes, stuefe ! src/utils/IdealGraphVisualizer/Bytecodes/src/main/java/com/sun/hotspot/igv/bytecodes/BytecodeViewTopComponent.java ! src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/ControlFlowTopComponent.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/BinaryParser.java ! src/utils/IdealGraphVisualizer/FilterWindow/src/main/java/com/sun/hotspot/igv/filterwindow/FilterTopComponent.java ! src/utils/IdealGraphVisualizer/Settings/src/main/java/com/sun/hotspot/igv/settings/Settings.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/BasicLogEvent.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogCleanupReader.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java ! src/utils/src/build/tools/commentchecker/CommentChecker.java ! src/utils/src/build/tools/dirdiff/DirDiff.java Changeset: 51a5731d Author: Magnus Ihse Bursie Date: 2021-11-12 14:12:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51a5731d6dc4b6f6feac920a4b8b49c15fd6b34f 8277016: Use blessed modifier order in jdk.httpserver Reviewed-by: dfuchs ! src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/Request.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java Changeset: aeba6530 Author: Andrew Leonard Date: 2021-11-12 14:43:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aeba65303479130d9bab74484accad5d7d116a40 8276743: Make openjdk build Zip Archive generation "reproducible" Reviewed-by: erikj, ihse ! make/Main.gmk ! make/ToolsJdk.gmk ! make/common/ZipArchive.gmk + make/jdk/src/classes/build/tools/makezipreproducible/MakeZipReproducible.java Changeset: 3b2585c0 Author: Coleen Phillimore Date: 2021-11-12 16:17:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3b2585c02bd9d66cc2c8b2d5c16e9a48f4280d07 8276658: Clean up JNI local handles code Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/gc/shared/concurrentGCThread.cpp ! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/jniHandles.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/nonJavaThread.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java Changeset: 5a2452c8 Author: Andrey Turbanov Committer: Daniel Fuchs Date: 2021-11-12 16:30:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5a2452c80e64b8b7a1799caa1a8a6e9e6a7dab6d 8274835: Remove unnecessary castings in java.base Reviewed-by: mullan, naoto, lancea, bpb ! src/java.base/share/classes/java/io/SequenceInputStream.java ! src/java.base/share/classes/java/lang/ClassValue.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/security/Signature.java ! src/java.base/share/classes/java/util/GregorianCalendar.java ! src/java.base/share/classes/java/util/HashSet.java ! src/java.base/share/classes/java/util/stream/ReferencePipeline.java ! src/java.base/share/classes/sun/net/www/MimeTable.java ! src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java ! src/java.base/share/classes/sun/security/provider/DSAPublicKey.java ! src/java.base/share/classes/sun/security/provider/certpath/PKIX.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/util/calendar/Era.java Changeset: 0d2980cd Author: Coleen Phillimore Date: 2021-11-12 17:03:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0d2980cdd1486b0689a71fc107a1d4c100bd3025 8258192: Obsolete the CriticalJNINatives flag Reviewed-by: mdoerr, shade ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/vm_version_arm_32.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/zero/sharedRuntime_zero.cpp ! src/hotspot/cpu/zero/vm_version_zero.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/prims/nativeLookup.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.java - test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/libCNCheckLongArgs.c - test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/LookUp.java - test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/libCNLookUp.c - test/hotspot/jtreg/gc/CriticalNative.java - test/hotspot/jtreg/gc/CriticalNativeArgs.java - test/hotspot/jtreg/gc/libCriticalNative.c - test/hotspot/jtreg/gc/stress/CriticalNativeStress.java Changeset: b85500e5 Author: Lance Andersen Date: 2021-11-12 17:12:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b85500e52479c48b02a96b28fddefa2b25d5d9bd 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File Reviewed-by: redestad, alanb ! src/java.base/share/classes/java/util/zip/ZipFile.java + test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java Changeset: 74f3e69d Author: Daniel D. Daugherty Date: 2021-11-12 18:46:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/74f3e69dc888685558408e663df5d32cb906991f 8277071: [BACKOUT] JDK-8276743 Make openjdk build Zip Archive generation "reproducible" Reviewed-by: erikj ! make/Main.gmk ! make/ToolsJdk.gmk ! make/common/ZipArchive.gmk - make/jdk/src/classes/build/tools/makezipreproducible/MakeZipReproducible.java Changeset: 176d21d6 Author: Daniel D. Daugherty Date: 2021-11-12 19:06:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/176d21d6c525f8fd9592db5b4975308ea0001856 8276824: refactor Thread::is_JavaThread_protected Reviewed-by: coleenp, rehn, dholmes ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 8c5f0304 Author: Man Cao Date: 2021-11-12 22:34:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8c5f03049196e66a4f8411bdd853b287134e7ce5 8276453: Undefined behavior in C1 LIR_OprDesc causes SEGV in fastdebug build Co-authored-by: Chuck Rasbold Co-authored-by: James Y Knight Reviewed-by: kvn, dlong ! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_FrameMap_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp ! src/hotspot/cpu/arm/c1_FrameMap_arm.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_CodeStubs_ppc.cpp ! src/hotspot/cpu/ppc/c1_FrameMap_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.hpp ! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp ! src/hotspot/cpu/s390/c1_FrameMap_s390.cpp ! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp ! src/hotspot/cpu/x86/c1_FrameMap_x86.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.hpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_FrameMap.hpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/barrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.hpp Changeset: 296780c7 Author: Thomas Stuefe Date: 2021-11-15 06:47:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/296780c7ae5c129d24997007600f428b697d3365 8276983: Small fixes to DumpAllocStat::print_stats Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/dumpAllocStats.cpp Changeset: ca2efb73 Author: Richard Reingruber Date: 2021-11-15 07:02:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ca2efb73f59112d9be2ec29db405deb4c58dd435 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend Reviewed-by: cjplummer, sspitsyn, rschmelter ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c + test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java Changeset: b231f5ba Author: Hamlin Li Date: 2021-11-15 10:08:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b231f5baa94c7104324cd206c1081b35fd27164c 8276921: G1: Remove redundant failed evacuation regions calculation in RemoveSelfForwardPtrHRClosure Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: fdcd16a3 Author: Pavel Rappo Date: 2021-11-15 11:25:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fdcd16a38fb9a14a819d68682f9666ebfe7285db 8277048: Tiny improvements to the specification text for java.util.Properties.load Reviewed-by: rriggs, iris, naoto ! src/java.base/share/classes/java/util/Properties.java Changeset: 02f79008 Author: Albert Mingkun Yang Date: 2021-11-15 12:46:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/02f79008828b3dcce3bd6492efaa43e99376c0c5 8276932: G1: Annotate methods with override explicitly in g1CollectedHeap.hpp Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 35a831d5 Author: Thomas Schatzl Date: 2021-11-15 14:34:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35a831d5a755de8f3c71653bd0a37190adddb8ae 8272170: Missing memory barrier when checking active state for regions Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CommittedRegionMap.inline.hpp Changeset: 7fc344dc Author: Hannes Walln?fer Date: 2021-11-15 15:53:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7fc344dc96008f277dacf5518b28447f3a598cde 8277028: Use service type documentation as fallback for @provides Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServices.java Changeset: 9046077f Author: Alexey Semenyuk Date: 2021-11-15 17:57:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9046077fe6ce7bb042fbd0fa1a80537cb4a60581 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional Reviewed-by: almatvee, herrick ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.control ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java ! test/jdk/tools/jpackage/linux/LinuxResourceTest.java ! test/jdk/tools/jpackage/linux/ReleaseTest.java Changeset: fe45835f Author: Alexey Semenyuk Date: 2021-11-15 17:57:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe45835f7cebfccd4544ae19d88bdc7f07560fbe 8274856: Failing jpackage tests with fastdebug/release build Reviewed-by: almatvee, herrick ! src/jdk.jpackage/linux/native/applauncher/LinuxLauncher.c ! src/jdk.jpackage/linux/native/libapplauncher/LinuxLauncherLib.cpp ! src/jdk.jpackage/share/native/applauncher/AppLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.h ! src/jdk.jpackage/share/native/applauncher/JvmLauncherLib.c ! src/jdk.jpackage/unix/native/common/UnixSysInfo.cpp ! src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp Changeset: 1830b8da Author: Thomas Schatzl Date: 2021-11-15 18:09:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1830b8da9028af430ee4791f310b5fc9cb1ff37d 8275056: Virtualize G1CardSet containers over heap region Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/g1CardSet.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1_globals.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegionBounds.hpp ! src/hotspot/share/gc/g1/heapRegionBounds.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/jtreg/gc/arguments/TestG1HeapRegionSize.java Changeset: db0c8d52 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-15 19:14:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db0c8d522704d2e12bce4ebeb9297b57e3789f4f 8274232: Cleanup unnecessary null comparison before instanceof check in jdk.jdi Reviewed-by: cjplummer, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ByteValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/FieldImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LocalVariableImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/StackFrameImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VoidValueImpl.java Changeset: 7a870418 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-15 19:18:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a870418a3e8de3b290ba71cbe4ca7979ec029f9 8275385: Change nested classes in jdk.jdi to static nested classes Reviewed-by: sspitsyn, amenkov, cjplummer ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SDE.java Changeset: 9326eb14 Author: Dean Long Date: 2021-11-15 21:09:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9326eb14617bf08e3376f854fc022e11d1ef34dd 8276095: ciReplay: replay failure due to incomplete ciMethodData information Reviewed-by: chagedorn, kvn ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/ci/ciMethodData.hpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciReplay.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciMethodData.java ! test/hotspot/jtreg/compiler/ciReplay/TestLambdas.java Changeset: a59c9b2a Author: Paul Sandoz Date: 2021-11-15 21:48:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a59c9b2ac277d6ff6be1700d91ff389f137e61ca 8271515: Integration of JEP 417: Vector API (Third Incubator) Co-authored-by: Sandhya Viswanathan Co-authored-by: Jatin Bhateja Co-authored-by: Ningsheng Jian Co-authored-by: Xiaohong Gong Co-authored-by: Eric Liu Co-authored-by: Jie Fu Co-authored-by: Vladimir Ivanov Co-authored-by: John R Rose Co-authored-by: Paul Sandoz Co-authored-by: Rado Smogura Reviewed-by: kvn, sviswanathan, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.cpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/forms.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/chaitin.cpp ! src/hotspot/share/opto/chaitin.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/matcher.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/postaloc.cpp ! src/hotspot/share/opto/regmask.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! src/hotspot/share/opto/vector.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! src/hotspot/share/prims/vectorSupport.cpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/growableArray.hpp ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template ! src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h + test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastTest.java + test/hotspot/jtreg/compiler/vectorapi/VectorMaskLoadStoreTest.java + test/hotspot/jtreg/compiler/vectorapi/VectorMemoryAlias.java Changeset: bd92674b Author: Calvin Cheung Date: 2021-11-16 02:34:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd92674be563ad291990216b7cdf061c498f5dd3 8276184: Exclude lambda proxy class from the CDS archive if its caller class is excluded Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! test/hotspot/jtreg/runtime/cds/appcds/LambdaContainsOldInf.java ! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaContainsOldInf.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaForOldInfInBaseArchive.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/OldClassInBaseArchive.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/RedefineCallerClassTest.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/RedefineCallerClass.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/Hello.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaContainsOldInfApp.java Changeset: e4362007 Author: Aleksey Shipilev Date: 2021-11-16 07:32:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4362007da8e40c076493364df91cf85960a03e7 8008243: Zero: Implement fast bytecodes Reviewed-by: rkennke, coleenp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.hpp ! src/hotspot/share/prims/jvmtiManageCapabilities.cpp Changeset: 7719a74c Author: Thomas Stuefe Date: 2021-11-16 07:49:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7719a74cec8c47fd036226b520a5fce7887386da 8277172: Remove stray comment mentioning instr_size_for_decode_klass_not_null on x64 Reviewed-by: dholmes ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: 1d79cfd3 Author: Stefan Johansson Date: 2021-11-16 08:27:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d79cfd3a16a71ec1bf93a0748e806b21a717b52 8276229: Stop allowing implicit updates in G1BlockOffsetTable Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: b8d33a2a Author: Thomas Stuefe Date: 2021-11-16 09:49:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b8d33a2a4e4ac1be322644102e8f09ce1435b4fb 8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/include/jmm.h ! src/hotspot/share/services/management.cpp ! src/jdk.management/share/native/libmanagement_ext/DiagnosticCommandImpl.c Changeset: 20f3872d Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:13:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/20f3872d1cd6257ab9c76bb998f8dc2d07bc1724 8274261: Use enhanced-for instead of plain 'for' in jdk.jcmd Reviewed-by: sspitsyn, cjplummer ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/ColumnFormat.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/OptionFormat.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/RawOutputFormatter.java Changeset: a9cb8bdb Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:14:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9cb8bdbaac7241959805c491b6d13b6e14f8966 8274168: Avoid String.compareTo == 0 to check String equality in java.management Reviewed-by: sspitsyn, dfuchs, cjplummer, dholmes ! src/java.management/share/classes/javax/management/BinaryRelQueryExp.java ! src/java.management/share/classes/javax/management/loading/MLet.java Changeset: 0bc26837 Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:15:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0bc268377ed5d2dd15bdd7283a77b59ad505e2b7 8274190: Use String.equals instead of String.compareTo in jdk.internal.jvmstat Reviewed-by: cjplummer, sspitsyn ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java Changeset: 9629627e Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:17:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9629627e2c8021c254517ac5463cc66723175fd9 8274163: Use String.equals instead of String.compareTo in jdk.jcmd Reviewed-by: cjplummer, amenkov, sspitsyn ! src/jdk.jcmd/share/classes/sun/tools/jps/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/OptionLister.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java Changeset: c06df25a Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:18:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c06df25a4fb76ee65d3fa99ec0579ca4a406c345 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent Reviewed-by: amenkov, cjplummer, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/DeadlockDetector.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/FindInHeapPanel.java Changeset: 1c45c8a0 Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:19:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c45c8a08287e2d8d7574eaa773850b7f0b33207 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module Reviewed-by: dfuchs, sspitsyn ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java ! src/java.management/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java Changeset: 7906eb05 Author: Hamlin Li Date: 2021-11-16 11:37:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7906eb050d4675092536048e8e21334767e397e6 8277119: Add asserts in GenericTaskQueueSet methods Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/taskqueue.hpp ! src/hotspot/share/gc/shared/taskqueue.inline.hpp Changeset: 9a9a157a Author: Jayathirth D V Date: 2021-11-16 13:18:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9a9a157a7d45cbfb016d4427931e1d5345210f7a 8276905: Use appropriate macosx_version_minimum value while compiling metal shaders Reviewed-by: ihse, kcr, erikj, prr ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: f3eb5014 Author: MeryKitty Committer: Tobias Hartmann Date: 2021-11-16 14:09:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f3eb5014aa75af4463308f52f2bc6e9fcd2da36c 8276162: Optimise unsigned comparison pattern Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/subnode.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestUnsignedComparison.java + test/micro/org/openjdk/bench/vm/compiler/UnsignedComparison.java Changeset: d5e47d6b Author: Yasumasa Suenaga Date: 2021-11-16 14:47:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5e47d6b84514edde23a8baff8c2274e5b3ca6bb 8277089: Use system binutils to build hsdis Reviewed-by: ihse ! make/autoconf/jdk-options.m4 ! src/utils/hsdis/README ! src/utils/hsdis/hsdis.c Changeset: e5ffdf91 Author: Dean Long Date: 2021-11-16 17:25:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e5ffdf9120c14b38e4c8794888d2002e2686ebfc 8276231: ciReplay: SIGSEGV when replay compiling lambdas Reviewed-by: iveresov, chagedorn ! src/hotspot/share/ci/ciReplay.cpp Changeset: b0a463fa Author: Alexander Zuev Date: 2021-11-16 19:01:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b0a463fa59a1c3c554f48267525729bf89a2c5be 8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes! Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java Changeset: cddc6ce4 Author: Daniel Jelinski Committer: Xue-Lei Andrew Fan Date: 2021-11-16 20:34:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cddc6ce44695cba4614c3405eb2b194d7c76489b 8275811: Incorrect instance to dispose Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/InputRecord.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java Changeset: 8ed384cf Author: Roger Riggs Date: 2021-11-16 20:53:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8ed384cfb655d97ba452033e06d18ca38e5fc9b0 8276609: Document setting property `jdk.serialFilter` to an invalid value throws `ExceptionInInitializerError` Reviewed-by: dfuchs, lancea ! src/java.base/share/classes/java/io/ObjectInputFilter.java Changeset: a77d8ddf Author: Ioi Lam Date: 2021-11-16 21:03:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a77d8ddf11fba33007a4f5c0468d69de23f10f6a 8276787: Improve warning messages for -XX:+RecordDynamicDumpInfo Reviewed-by: ccheung, stuefe ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/dynamicArchive.hpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/thread.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 23e5117a Author: Jaikiran Pai Date: 2021-11-17 03:20:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23e5117a55b3f3d0e3d26bf2d481f4ad1c99af57 8276559: (httpclient) Consider adding an HttpRequest.Builder.HEAD method to build a HEAD request. Reviewed-by: cstein, dfuchs ! src/java.net.http/share/classes/java/net/http/HttpRequest.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpRequestBuilderImpl.java ! test/jdk/java/net/httpclient/HeadTest.java ! test/jdk/java/net/httpclient/HttpRequestBuilderTest.java ! test/jdk/java/net/httpclient/HttpRequestNewBuilderTest.java ! test/jdk/java/net/httpclient/RequestBuilderTest.java Changeset: 08f65a59 Author: Fairoz Matte Committer: Jayathirth D V Date: 2021-11-17 06:13:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/08f65a59a7bd387974d94253ec7093524a3e92f1 8277313: Validate header failed for test/jdk/java/net/httpclient/HeadTest.java Reviewed-by: jdv ! test/jdk/java/net/httpclient/HeadTest.java Changeset: 9aa30de4 Author: Faye Gao Committer: Tobias Hartmann Date: 2021-11-17 08:19:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9aa30de4bb55357ddf0900e6103062f02e85753b 8275317: AArch64: Support some type conversion vectorization in SLP Reviewed-by: thartmann, ngasson ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/vectornode.cpp ! test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java ! test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java ! test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java Changeset: e9934e12 Author: Albert Mingkun Yang Date: 2021-11-17 09:59:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e9934e1243929514e147ecdd3cefa74168ed0500 8277221: G1: Remove methods without implementations in G1CollectedHeap Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 2af9e597 Author: Kevin Walls Date: 2021-11-17 11:59:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2af9e5976fdf94afc7dbe5ad7827553818057bae 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test Reviewed-by: jiefu, sspitsyn ! test/jdk/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java ! test/jdk/sun/jvmstat/monitor/HostIdentifier/testcases - test/jdk/sun/tools/jps/TestJpsHostName.java Changeset: 9f2f46ee Author: Harold Seigel Date: 2021-11-17 14:25:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f2f46ee4576d9cd0190530949e5e50f796a6bdc 8275037: Test vmTestbase/nsk/sysdict/vm/stress/btree/btree011/btree011.java crashes with memory exhaustion on Windows Reviewed-by: coleenp ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/GenClassesBuilder.java ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/SysDictTest.java Changeset: 8f5a8f74 Author: Alexander Zuev Date: 2021-11-17 17:36:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8f5a8f740b62c27cc244debe57aaa2975f84a694 8264293: Create implementation for NSAccessibilityMenu protocol peer 8264296: Create implementation for NSAccessibilityPopUpButton protocol peer 8264295: Create implementation for NSAccessibilityMenuItem protocol peer 8264294: Create implementation for NSAccessibilityMenuBar protocol peer Reviewed-by: pbansal, ant ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuBarAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuBarAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuItemAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuItemAccessibility.m Changeset: b6876649 Author: Alex Kasko Committer: Zhengyu Gu Date: 2021-11-17 17:48:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6876649a82bed508d817ccbde1600d00937e4b2 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points Reviewed-by: bpb, shade ! test/jdk/java/nio/file/FileStore/Basic.java Changeset: a907b2b1 Author: Coleen Phillimore Date: 2021-11-17 19:53:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a907b2b144f2af27392eb7c2f9656fbb1a759618 8276177: nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption failed with "assert(def_ik->is_being_redefined()) failed: should be being redefined to get here" Reviewed-by: hseigel, sspitsyn ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/utilities/accessFlags.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 262d0700 Author: Weijun Wang Date: 2021-11-17 20:03:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/262d07001babcbe7f9acd2053aa3b7bac304cf85 8277246: Check for NonRepudiation as well when validating a TSA certificate Reviewed-by: xuelei, mullan ! src/java.base/share/classes/sun/security/validator/EndEntityChecker.java ! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java Changeset: 8881f29b Author: Dean Long Date: 2021-11-17 20:18:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8881f29bc83336bcbc0e8ff0cf1d2bbe55172f5c 8277310: ciReplay: @cpi MethodHandle references not resolved Reviewed-by: chagedorn, thartmann ! src/hotspot/share/ci/ciReplay.cpp Changeset: 007ad7c7 Author: Joe Darcy Date: 2021-11-17 20:23:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/007ad7c77c6277ce733386b4402b787d81dd41cf 8277303: Terminology mismatch between JLS17-3.9 and SE17's javax.lang.model.SourceVersion method specs Reviewed-by: iris, jjg ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Changeset: d8c02802 Author: Dean Long Date: 2021-11-17 20:26:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8c0280273fa9f8e113088d6a43a4af076cd4f87 8277316: ciReplay: dump_replay_data is not thread-safe Reviewed-by: chagedorn, thartmann ! src/hotspot/share/ci/ciEnv.cpp Changeset: 6bb04626 Author: Sean Coffey Date: 2021-11-17 20:50:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6bb04626af6574ef1e8d4b7dad0389d4b59f5d08 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE Reviewed-by: weijun ! src/java.base/share/classes/sun/security/pkcs/PKCS9Attributes.java ! test/jdk/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 45a60db5 Author: Albert Mingkun Yang Date: 2021-11-17 21:02:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/45a60db5a0aa78fa9eb1c2899bd167c136e0fa03 8277045: G1: Remove unnecessary set_concurrency call in G1ConcurrentMark::weak_refs_work Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp Changeset: ce4471f8 Author: Daniel D. Daugherty Date: 2021-11-17 21:23:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce4471f806e51bc9f9ad746b69ba490443947110 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 8277351: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on macosx-x64 Reviewed-by: tschatzl, bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: 29e552c0 Author: Sergey Bylokhov Date: 2021-11-17 22:21:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/29e552c03a2825f9526330072668a1d63ac68fd4 8272358: Some tests may fail when executed with other locales than the US Reviewed-by: aivanov ! test/langtools/jdk/jshell/ToolBasicTest.java ! test/langtools/jdk/jshell/ToolSimpleTest.java ! test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java ! test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java Changeset: 231fb61a Author: Naoto Sato Date: 2021-11-18 01:12:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/231fb61aaeae04787c06a4c972197943d9085627 8276970: Default charset for PrintWriter that wraps PrintStream Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java + test/jdk/java/io/PrintStream/InheritEncodingTest.java Changeset: b8453ebd Author: Naoto Sato Date: 2021-11-18 01:13:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b8453ebdb471e08cc8d62c777f33ad52902f67d7 8275007: Java fails to start with null charset if LC_ALL is set to certain locales Reviewed-by: rriggs, iris, joehw, alanb ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/native/libjava/jni_util.c Changeset: 81938001 Author: Fei Gao Committer: Ningsheng Jian Date: 2021-11-18 02:41:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81938001f9bae56c59f4e18b7756089f2cf0bf74 8274179: AArch64: Support SVE operations with encodable immediates Reviewed-by: aph, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.cpp ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h ! test/hotspot/jtreg/compiler/codegen/TestByteVect.java ! test/hotspot/jtreg/compiler/codegen/TestCharVect.java ! test/hotspot/jtreg/compiler/codegen/TestIntVect.java ! test/hotspot/jtreg/compiler/codegen/TestLongVect.java ! test/hotspot/jtreg/compiler/codegen/TestShortVect.java Changeset: 91607436 Author: Prasanta Sadhukhan Date: 2021-11-18 04:33:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/91607436b79126ccb999deaf38a98209dbfe6ec1 8276058: Some swing test fails on specific CI macos system Reviewed-by: prr, kizune ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java ! test/jdk/javax/swing/JButton/8151303/PressedIconTest.java ! test/jdk/javax/swing/JInternalFrame/8069348/bug8069348.java ! test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java Changeset: 2f4b5405 Author: Doug Simon Date: 2021-11-18 08:32:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f4b5405f0b53782f3ed5274f68b31eb968efb6d 8276314: [JVMCI] check alignment of call displacement during code installation Reviewed-by: kvn ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp Changeset: db55f927 Author: Ioi Lam Date: 2021-11-18 08:49:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db55f9272c0889f4ea4dee0f4aa3d9613fadb2f8 8277343: dynamicArchive/SharedArchiveFileOption.java failed: '-XX:+RecordDynamicDumpInfo is unsupported when a dynamic CDS archive is specified in -XX:SharedArchiveFile:' missing Reviewed-by: hseigel, ccheung ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicArchiveTestBase.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java Changeset: 0a65e8b2 Author: Andrey Turbanov Committer: Alexey Ivanov Date: 2021-11-18 10:48:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0a65e8b282fd41e57108422fbd140527d9697efd 8276794: Change nested classes in java.desktop to static nested classes Reviewed-by: serb, aivanov ! src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/DHTMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/DQTMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/SOSMarkerSegment.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopPaneUI.java ! src/java.desktop/share/classes/com/sun/media/sound/EventDispatcher.java ! src/java.desktop/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java ! src/java.desktop/share/classes/com/sun/media/sound/SunFileWriter.java ! src/java.desktop/share/classes/java/awt/CardLayout.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Polygon.java ! src/java.desktop/share/classes/java/awt/ScrollPane.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/print/Book.java ! src/java.desktop/share/classes/java/beans/XMLEncoder.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioInputStream.java ! src/java.desktop/share/classes/javax/swing/GroupLayout.java ! src/java.desktop/share/classes/javax/swing/JComboBox.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/KeyboardManager.java ! src/java.desktop/share/classes/javax/swing/RepaintManager.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/java.desktop/share/classes/javax/swing/text/DefaultHighlighter.java ! src/java.desktop/share/classes/javax/swing/text/ElementIterator.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/StringContent.java ! src/java.desktop/share/classes/javax/swing/text/StyleContext.java ! src/java.desktop/share/classes/javax/swing/text/html/ImageView.java ! src/java.desktop/share/classes/javax/swing/text/html/TableView.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFReader.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/java.desktop/share/classes/sun/awt/PlatformFont.java ! src/java.desktop/share/classes/sun/java2d/loops/RenderCache.java ! src/java.desktop/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/GeneralCompositePipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/SpanClipRenderer.java ! src/java.desktop/share/classes/sun/print/PrintJob2D.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/java.desktop/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextFieldPeer.java ! src/java.desktop/unix/classes/sun/font/X11GB2312.java ! src/java.desktop/unix/classes/sun/font/X11GBK.java ! src/java.desktop/unix/classes/sun/font/X11KSC5601.java ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java ! src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DRenderer.java Changeset: 77cc5088 Author: Albert Mingkun Yang Date: 2021-11-18 10:52:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77cc508802899b370f1cdf592331f81efb8d9208 8277215: Remove redundancy in ReferenceProcessor constructor args Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 2c06bca9 Author: Erik ?sterlund Date: 2021-11-18 11:17:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2c06bca98fcf9d129d6085e26c225fb26368a558 8266368: Inaccurate after_unwind hook in C2 exception handler Reviewed-by: dlong, thartmann ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: 38345bd2 Author: Evgeny Astigeevich Committer: Volker Simonis Date: 2021-11-18 11:18:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38345bd28db83371676f1685806ddc207a833879 8277137: Set OnSpinWaitInst/OnSpinWaitInstCount defaults to "isb"/1 for Arm Neoverse N1 Reviewed-by: phh, aph, ngasson ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java Changeset: b3a62b48 Author: Harold Seigel Date: 2021-11-18 13:18:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b3a62b48816358ac7dadde4e7893190500ca7b79 8276795: Deprecate seldom used CDS flags Reviewed-by: dholmes, ccheung, iklam ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/intrinsics/klass/TestIsPrimitive.java ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: a44b45fd Author: Sean Mullan Date: 2021-11-18 13:48:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a44b45fdf31275a2c1e9d1d0132874a7de45f8ee 4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath Reviewed-by: valeriep, rriggs ! src/java.base/share/classes/java/security/cert/CertPath.java ! src/java.base/share/classes/java/security/cert/Certificate.java Changeset: 00c388b4 Author: Erik ?sterlund Date: 2021-11-18 14:32:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00c388b4aba41d5f0874585e9c0a33c4571805f6 8259643: ZGC can return metaspace OOM prematurely Reviewed-by: stefank, pliden, stuefe ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/memory/metaspace.cpp + src/hotspot/share/memory/metaspaceCriticalAllocation.cpp + src/hotspot/share/memory/metaspaceCriticalAllocation.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: d93b238f Author: Erik ?sterlund Date: 2021-11-18 14:44:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d93b238f9725727ae1e2e9f203943b5ddf778f35 8277180: Intrinsify recursive ObjectMonitor locking for C2 x64 and A64 Reviewed-by: aph, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp Changeset: 276bfcd1 Author: Prasanta Sadhukhan Date: 2021-11-18 15:17:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/276bfcd1a115f90dde644abef79d64bb61788c75 8277407: javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java fails to compile after JDK-8276058 Reviewed-by: dcubed ! test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java Changeset: 354a34ea Author: Albert Mingkun Yang Date: 2021-11-18 15:54:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/354a34ea2077c9372e585adb1303df604827a2e2 8277336: Improve CollectedHeap::safepoint_workers comments Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/shared/collectedHeap.hpp Changeset: 5d249c46 Author: Alexander Zuev Date: 2021-11-18 16:07:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5d249c46abc8dfdc3acdaff41d26f3bd9ba84731 8275071: [macos] A11y cursor gets stuck when combobox is closed Reviewed-by: serb, pbansal ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java Changeset: ce0f00f6 Author: Thomas Schatzl Date: 2021-11-18 16:59:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce0f00f66e78a504d5e40a25fa213325ec0af394 8276093: Improve naming in closures to iterate over card sets Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/g1CardSet.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp Changeset: 03473b4c Author: Sergey Bylokhov Date: 2021-11-18 18:25:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/03473b4c271b2ec7f0ebdb0edabadf7f36816b9d 8270874: JFrame paint artifacts when dragged from standard monitor to HiDPI monitor Reviewed-by: jdv ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp ! test/jdk/java/awt/Window/WindowResizingOnDPIChanging/WindowResizingOnMovingToAnotherDisplay.java Changeset: 8db0c361 Author: Daniel D. Daugherty Date: 2021-11-18 18:40:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8db0c361a39cf10d373c3d2dfa54267cf53452db 8277414: ProblemList runtime/CommandLine/VMDeprecatedOptions.java on windows-x64 Reviewed-by: mikael, iklam ! test/hotspot/jtreg/ProblemList.txt Changeset: 57eb8647 Author: Niklas Radomski Committer: Martin Doerr Date: 2021-11-18 19:00:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/57eb864765f38185f8db8f1d37681d6cfe2a3c73 8276927: [PPC64] Port shenandoahgc to linux on ppc64le Reviewed-by: rkennke, ihse, mdoerr ! make/autoconf/jvm-features.m4 ! make/hotspot/gensrc/GensrcAdlc.gmk ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.hpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoah_ppc.ad ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Changeset: 36bd4a35 Author: Harold Seigel Date: 2021-11-18 20:06:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36bd4a35fbee077c00c1f4240f1f02f4d7d5f656 8277404: Test VMDeprecatedOptions.java failing with Unable to create shared archive file Reviewed-by: dcubed ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 89b125f4 Author: Roman Kennke Date: 2021-11-18 21:32:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/89b125f4d4d6a467185b4b39861fd530a738e67f 8275527: Refactor forward pointer access Reviewed-by: tschatzl, stefank ! src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/oops/oop.inline.hpp Changeset: 839033ba Author: Man Cao Date: 2021-11-18 23:35:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/839033baf61ca7f10437e8e53b2114b081d97ea9 8276976: Rename LIR_OprDesc to LIR_Opr Co-authored-by: Chuck Rasbold Reviewed-by: thartmann, iveresov ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIR_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_LIR_arm.cpp ! src/hotspot/cpu/ppc/c1_LIR_ppc.cpp ! src/hotspot/cpu/s390/c1_LIR_s390.cpp ! src/hotspot/cpu/x86/c1_LIR_x86.cpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/c1/c1_LinearScan.cpp ! src/hotspot/share/c1/c1_LinearScan.hpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp Changeset: 2f0bde1a Author: Yi Yang Date: 2021-11-19 02:04:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f0bde1a658b0910304c110920a2e8ccbe4557f8 8277102: Dubious PrintCompilation output Reviewed-by: thartmann, dnsimon ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compileTask.hpp ! test/hotspot/jtreg/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java Changeset: 47564cae Author: Tobias Hartmann Date: 2021-11-19 07:07:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47564caeb0628e5c03a0e7f04093adce77d6dd3b 8275643: C2's unaryOp vector intrinsic does not properly handle LongVector.neg Reviewed-by: chagedorn, sviswanathan ! src/hotspot/share/prims/vectorSupport.cpp + test/hotspot/jtreg/compiler/vectorapi/TestLongVectorNeg.java Changeset: f34f1190 Author: Tobias Hartmann Date: 2021-11-19 07:13:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f34f119080b4e8baf396fb26c21d572dd432fd91 8277213: CompileTask_lock is acquired out of order with MethodCompileQueue_lock Reviewed-by: rbackman, coleenp ! src/hotspot/share/compiler/compileTask.hpp Changeset: 2f20b0d8 Author: Jan Lahoda Date: 2021-11-19 07:49:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f20b0d8daca6bdc53b4b9e1837c428930d34236 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/jdk/jshell/ErrorRecoveryTest.java + test/langtools/tools/javac/attr/AttrRecoveryTest.java Changeset: 3a76d397 Author: Tobias Hartmann Date: 2021-11-19 08:23:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3a76d397949ad22e4786476e583cc9d33c015214 8277324: C2 compilation fails with "bad AD file" on x86-32 after JDK-8276162 due to missing match rule Reviewed-by: chagedorn, roland ! src/hotspot/cpu/x86/x86_32.ad Changeset: 7a046e0f Author: Albert Mingkun Yang Date: 2021-11-19 08:31:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7a046e0f765e0ad04fd52c9a882c5d90b085bc00 8277371: Remove unnecessary DefNewGeneration::ref_processor_init() Reviewed-by: stefank, tschatzl, mli ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/shared/generation.hpp Changeset: 11d819d6 Author: Hamlin Li Date: 2021-11-19 10:15:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11d819d68a3ce2ae0973b496141c52aa419f90f0 8277439: G1: Correct include guard name in G1EvacFailureObjectsSet.hpp Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp Changeset: b15e6f07 Author: Jie Fu Date: 2021-11-19 10:38:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b15e6f076afe5ac68e9af68756860d0b25adea4b 8277449: compiler/vectorapi/TestLongVectorNeg.java fails with release VMs Reviewed-by: thartmann, chagedorn ! test/hotspot/jtreg/compiler/vectorapi/TestLongVectorNeg.java Changeset: 21d73270 Author: duke Date: 2021-11-19 11:00:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/21d732703b56f481fd3bed35881dfa5efbe29cdf Automatic merge of jdk:master into master Changeset: e47a8d69 Author: J. Duke Committer: Jorn Vernee Date: 2021-11-19 14:57:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e47a8d6995a9119b5bd65a6e1d329a4bf80f58e1 Merge master ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/utilities/growableArray.hpp ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! test/jdk/ProblemList.txt ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/utilities/growableArray.hpp ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! test/jdk/ProblemList.txt Changeset: cb38a18f Author: duke Date: 2021-11-19 14:58:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb38a18f55249139e2d347bf3178d7e12c8fa63d Automatic merge of foreign-memaccess+abi into foreign-jextract From stephanedubedat666 at gmail.com Fri Nov 19 15:18:01 2021 From: stephanedubedat666 at gmail.com (=?UTF-8?Q?St=C3=A9phane_Dubedat?=) Date: Fri, 19 Nov 2021 16:18:01 +0100 Subject: Support for Matrix Extension Message-ID: Intel next server CPU iteration Sapphire rappids will introduce a new x86 extension name AMX. This potentially disruptive extension allows for hardware accelerated SIMD Matrix operations! https://fuse.wikichip.org/news/3600/the-x86-advanced-matrix-extension-amx-brings-matrix-operations-to-debut-with-sapphire-rapids/ https://en.wikichip.org/wiki/x86/amx Note that ARM also has an analogue extension: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/scalable-matrix-extension-armv9-a-architecture So 1) The vector API should expose an explicit API for leveraging those new, majorly useful, SIMD instructions 2) The JVM/Vector API could leverage sometimes those instructions automatically even when not specified by the user, if supported at runtime and detecting patterns of matrices operations? Maybe this could be useful for more things that matrix operations such as N dimensional arrays in general? -> https://github.com/eclipse/deeplearning4j/tree/master/nd4j Ndarray are very useful as can be seen by their widespread use on the Python ecosystem through Numpy see also this SIMD version https://github.com/JetBrains-Research/viktor From jbhateja at openjdk.java.net Sat Nov 20 03:59:26 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sat, 20 Nov 2021 03:59:26 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:vectorIntrinsics+compress In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:13:23 GMT, Sandhya Viswanathan wrote: > Merge vectorIntrinsics+compress into vectorIntrinsics. > @nsjian need your help to update test/hotspot/gtest/aarch64/asmtest.out.h. > > Best Regards, > Sandhya Marked as reviewed by jbhateja (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/167 From themode at outlook.fr Sun Nov 21 07:33:11 2021 From: themode at outlook.fr (Felix Cravic) Date: Sun, 21 Nov 2021 07:33:11 +0000 Subject: Support for allocation of executable memory Message-ID: Hello, I was wondering if there has ever been any discussion about supporting allocation of executable memory (and then its execution). The use cases I have in mind are emulation, very hot paths requiring specialized assembly (which could still fallback to jvm bytecode if unavailable), and a potential option to keep the whole application written in a JVM language. I doubt that such addition would drastically change the API, perhaps some concern about OS specific restrictions (e.g. write-xor-execute memory protection), and platform not supporting JIT compilation at all (IOS, potentially problematic for Graal & project Leyden) Discussion would be appreciated! From martin.pernollet at protonmail.com Sun Nov 21 17:39:24 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Sun, 21 Nov 2021 17:39:24 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: =?us-ascii?Q?___<8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com>__<3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a=5Frexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=3D@protonmail.com>_<8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com>__<-QTuGDa0nmGTEPQ9e09MZxEU9ozr5M4FRwmJvR330RmH9yJsaRFWk0Iat-WWquO9MFmpmJst0bsK-JTJfjM2cDsdbVl4z9QjcRK?= =?us-ascii?Q?qkUftG6U=3D@protonmail.com>_?= Message-ID: Hi, The UnsatisfiedLinkError was triggered while invoking a method relying on a null method handle. When invoking jextract, I provided an include dir with multiple header files (usr/include/GL) but an incomplete list of libraries. The code is generated correctly and the user of this generated code don't see any problem at compile time. However, when running the program, glut_h will only map a subset of the generated method handles to the native libs. It would be convenient to get warnings about it when the program starts. Would you recommend a way to iterate over all generated method handles to check those that are null? /usr/lib/jvm/jdk-17-panama/bin/jextract -d ./src/main/java/ --source -t opengl.ubuntu.v20 \ -lGL \ -l/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 \ -l/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1 \ << that one was missing -I /usr/include/GL \ -C-F/usr/include/GL \ /usr/include/GL/glut.h public class glut_h extends glut_h_6 { static { System.loadLibrary("GL"); System.load("/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0"); System.load("/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1"); // fixing jextract lib list let glut_h map the metod handle to the native libs } Cheers, Martin ??????? Original Message ??????? Le lundi 15 novembre 2021 ? 11:43, Maurizio Cimadamore a ?crit : > Hi, > > from the top of my head, this looks like an exception thrown while you > > are executing an upcall. And it also looks like you are missing some of > > the latest patches which will generate a "normal" stack trace. So you > > only see the exception name (UnsatisfiedLink). > > As a general rule, if an exception occurs when an upcall is executing, > > only option is to exit the Java program, so that we don't leave the > > native code in a potentially bad state. > > But more recent releases of the linker API do a better job at presenting > > this as an "exception" (although one that cannot be caught) rather than > > a blunt crash. > > If you can't update to a newer build, I'd look into all upcall code, > > looking for all pieces of code which might do System.load/loadLibrary. > > Maurizio > > On 15/11/2021 07:33, Martin Pernollet wrote: > > > Hi, > > > > I am now on Ubuntu. The original teapot sample is working (just > > > > required to change glutDisplayFunc$func to glutDisplayFunc$callback). > > > > I got an UnstasfiedLinkException with other programs. I wonder if you > > > > have a suggestion to help me understand my mistake? LDD command does > > > > not help. Like for the NPE, we lack a bit of info for debugging. > > > > Console says > > > > Uncaught exception: > > > > java.lang.UnsatisfiedLinkError > > > > {0x0000000091ac9b58} - klass: 'java/lang/UnsatisfiedLinkError' > > > > A fatal error has been detected by the Java Runtime Environment: > > ================================================================ > > > > #? Internal Error (universalUpcallHandler.cpp:113), pid=33668, tid=33677 > > > > #? Error: ShouldNotReachHere() > > > > Core dump says (see attached the complete core dump file) > > > > Current thread (0x00007f5d580268c0):? JavaThread "main" > > > > [_thread_in_Java, id=35593, stack(0x00007f5d5f59e000,0x00007f5d5f69f000)] > > > > Stack: [0x00007f5d5f59e000,0x00007f5d5f69f000], > > > > sp=0x00007f5d5f69c8b0,? free space=1018k > > > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > > > > C=native code) > > > > V? [libjvm.so+0xd993a3] > > > > ProgrammableUpcallHandler::handle_uncaught_exception(oopDesc*)+0x43 > > > > v? ~BufferBlob::panama_upcall_stub > > > > C? [libglut.so.3.9.0+0x20895]? glutMainLoopEvent+0x2a5 > > > > Register to memory mapping: > > > > RAX=0x00007f5d60cc4000 points into unknown readable memory: > > > > 0x0000000000000058 | 58 00 00 00 00 00 00 00 > > > > RBX=0x00007f5d4184556a is at code_begin+842 in > > > > [CodeBlob (0x00007f5d41845190)] > > > > Framesize: 0 > > > > BufferBlob (0x00007f5d41845190) used for panama_upcall_stub > > > > RCX=0x000000000000000a is an unknown value > > > > RDX=0x0 is NULL > > > > RSP=0x00007f5d5f69c8b0 is pointing into the stack for thread: > > > > 0x00007f5d580268c0 > > > > RBP=0x00007f5d5f69c8c0 is pointing into the stack for thread: > > > > 0x00007f5d580268c0 > > > > RSI=0x0000000000000071 is an unknown value > > > > RDI=0x00007f5d606f6108: in > > > > /usr/lib/jvm/jdk-17-panama/lib/server/libjvm.so at 0x00007f5d5f7f9000 > > > > R8 =0x0 is NULL > > > > R9 =0x00007f5d5f69c8a0 is pointing into the stack for thread: > > > > 0x00007f5d580268c0 > > > > R10=0x0 is NULL > > > > R11=0x0 is NULL > > > > R12=0x0000000091d82828 is an oop: java.lang.UnsatisfiedLinkError > > > > {0x0000000091d82828} - klass: 'java/lang/UnsatisfiedLinkError' > > > > R13=0x00007f5d1c42fbdc is pointing into metadata > > > > R14=0x00007f5d5f69c8c8 is pointing into the stack for thread: > > > > 0x00007f5d580268c0 > > > > R15=0x00007f5d580268c0 is a thread > > > > I verified with LDD if the lib I am linking to has dependencies > > > > problem but it seams to be ok. > > > > ldd --verbose /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 > > > > linux-vdso.so.1 (0x00007ffc37dcd000) > > > > libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007effdf322000) > > > > libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007effdf1e5000) > > > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007effdf096000) > > > > libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007effdf084000) > > > > libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 > > > > (0x00007effdf07d000) > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007effdee8b000) > > > > libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 > > > > (0x00007effdedd1000) > > > > libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007effded9d000) > > > > libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007effded73000) > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007effded6d000) > > > > /lib64/ld-linux-x86-64.so.2 (0x00007effdf608000) > > > > libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007effded58000) > > > > libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007effded50000) > > > > libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007effded48000) > > > > libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007effded2e000) > > > > Version information: > > > > /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0: > > > > libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6 > > > > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libGL.so.1: > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libX11.so.6: > > > > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > > > > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.26) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libm.so.6: > > > > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libXi.so.6: > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libXxf86vm.so.1: > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libc.so.6: > > > > ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 > > > > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > > > /lib/x86_64-linux-gnu/libGLdispatch.so.0: > > > > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libGLX.so.0: > > > > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libxcb.so.1: > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libdl.so.2: > > > > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > > > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libXext.so.6: > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libXau.so.6: > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libXdmcp.so.6: > > > > libbsd.so.0 (LIBBSD_0.2) => /lib/x86_64-linux-gnu/libbsd.so.0 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > /lib/x86_64-linux-gnu/libbsd.so.0: > > > > libc.so.6 (GLIBC_2.25) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.16) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.8) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 From zjx001202 at gmail.com Sun Nov 21 18:19:21 2021 From: zjx001202 at gmail.com (Glavo) Date: Mon, 22 Nov 2021 02:19:21 +0800 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: I don't think Panama should provide special support for it. To do this, you just need to create the binding of the relevant system API (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) with the foreign linker API and call it. Felix Cravic ?2021?11?22??? ??1:01??? > Hello, I was wondering if there has ever been any discussion about > supporting allocation of executable memory (and then its execution). The > use cases I have in mind are emulation, very hot paths requiring > specialized assembly (which could still fallback to jvm bytecode if > unavailable), and a potential option to keep the whole application written > in a JVM language. > > I doubt that such addition would drastically change the API, perhaps some > concern about OS specific restrictions (e.g. write-xor-execute memory > protection), and platform not supporting JIT compilation at all (IOS, > potentially problematic for Graal & project Leyden) > > Discussion would be appreciated! > From themode at outlook.fr Sun Nov 21 18:41:31 2021 From: themode at outlook.fr (Felix Cravic) Date: Sun, 21 Nov 2021 18:41:31 +0000 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: I agree that there are reasons why it could not have its place in Panama, like OS limitations complicating the API design & it being another pretty unsafe feature. I however disagree with the "just", which would involve maintaining a native dependency and building it for every potential platform, not to mention the fact that every execution will have to pass through JNI/Linker API. By that point I doubt that Java would be the right tool for the job, or is it perhaps what you meant? ________________________________ De : Glavo Envoy? : dimanche 21 novembre 2021 19:19 ? : Felix Cravic Cc : panama-dev at openjdk.java.net Objet : Re: Support for allocation of executable memory I don't think Panama should provide special support for it. To do this, you just need to create the binding of the relevant system API (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) with the foreign linker API and call it. Felix Cravic > ?2021?11?22??? ??1:01??? Hello, I was wondering if there has ever been any discussion about supporting allocation of executable memory (and then its execution). The use cases I have in mind are emulation, very hot paths requiring specialized assembly (which could still fallback to jvm bytecode if unavailable), and a potential option to keep the whole application written in a JVM language. I doubt that such addition would drastically change the API, perhaps some concern about OS specific restrictions (e.g. write-xor-execute memory protection), and platform not supporting JIT compilation at all (IOS, potentially problematic for Graal & project Leyden) Discussion would be appreciated! From zjx001202 at gmail.com Sun Nov 21 19:00:35 2021 From: zjx001202 at gmail.com (Glavo) Date: Mon, 22 Nov 2021 03:00:35 +0800 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: > > which would involve maintaining a native dependency and building it for > every potential platform If it needs to be implemented through JNI, you may be right. However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code. Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms. not to mention the fact that every execution will have to pass through > JNI/Linker API I don't understand why you should emphasize this. Does this bring any additional problems? I however disagree with the "just" This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related. So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only". Felix Cravic ?2021?11?22??? ??2:41??? > I agree that there are reasons why it could not have its place in Panama, > like OS limitations complicating the API design & it being another pretty > unsafe feature. > I however disagree with the "just", which would involve maintaining a > native dependency and building it for every potential platform, not to > mention the fact that every execution will have to pass through JNI/Linker > API. By that point I doubt that Java would be the right tool for the job, > or is it perhaps what you meant? > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 19:19 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > I don't think Panama should provide special support for it. > > To do this, you just need to create the binding of the relevant system API > (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) > with the foreign linker API and call it. > > Felix Cravic ?2021?11?22??? ??1:01??? > > Hello, I was wondering if there has ever been any discussion about > supporting allocation of executable memory (and then its execution). The > use cases I have in mind are emulation, very hot paths requiring > specialized assembly (which could still fallback to jvm bytecode if > unavailable), and a potential option to keep the whole application written > in a JVM language. > > I doubt that such addition would drastically change the API, perhaps some > concern about OS specific restrictions (e.g. write-xor-execute memory > protection), and platform not supporting JIT compilation at all (IOS, > potentially problematic for Graal & project Leyden) > > Discussion would be appreciated! > > From zjx001202 at gmail.com Sun Nov 21 19:04:38 2021 From: zjx001202 at gmail.com (Glavo) Date: Mon, 22 Nov 2021 03:04:38 +0800 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: Sorry, in the last sentence of that email, I wanted to say "just" instead of "only". I am using Google translate to write email. Please forgive me for my problems in grammar and words. Glavo ?2021?11?22??? ??3:00??? > which would involve maintaining a native dependency and building it for >> every potential platform > > > If it needs to be implemented through JNI, you may be right. > > However, for Panama, although we still need to use different codes for > different operating systems, all this can be implemented through pure java > code. > > Additional dependencies are unnecessary because these functions should be > part of the operating system. Because it only needs to be implemented in > Java code, it is not necessary to compile on multiple platforms. > > not to mention the fact that every execution will have to pass through >> JNI/Linker API > > > I don't understand why you should emphasize this. Does this bring any > additional problems? > > I however disagree with the "just" > > This implementation does improve the difficulty of user code maintenance, > but this function itself is low-level, unsafe and platform related, and the > code using it is often platform related. > So I believe that when it is really needed, the problems caused by this > part are relatively insignificant, so I use the word "only". > > Felix Cravic ?2021?11?22??? ??2:41??? > >> I agree that there are reasons why it could not have its place in Panama, >> like OS limitations complicating the API design & it being another pretty >> unsafe feature. >> I however disagree with the "just", which would involve maintaining a >> native dependency and building it for every potential platform, not to >> mention the fact that every execution will have to pass through JNI/Linker >> API. By that point I doubt that Java would be the right tool for the job, >> or is it perhaps what you meant? >> ------------------------------ >> *De :* Glavo >> *Envoy? :* dimanche 21 novembre 2021 19:19 >> *? :* Felix Cravic >> *Cc :* panama-dev at openjdk.java.net >> *Objet :* Re: Support for allocation of executable memory >> >> I don't think Panama should provide special support for it. >> >> To do this, you just need to create the binding of the relevant system >> API (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on >> Linux) with the foreign linker API and call it. >> >> Felix Cravic ?2021?11?22??? ??1:01??? >> >> Hello, I was wondering if there has ever been any discussion about >> supporting allocation of executable memory (and then its execution). The >> use cases I have in mind are emulation, very hot paths requiring >> specialized assembly (which could still fallback to jvm bytecode if >> unavailable), and a potential option to keep the whole application written >> in a JVM language. >> >> I doubt that such addition would drastically change the API, perhaps some >> concern about OS specific restrictions (e.g. write-xor-execute memory >> protection), and platform not supporting JIT compilation at all (IOS, >> potentially problematic for Graal & project Leyden) >> >> Discussion would be appreciated! >> >> From zjx001202 at gmail.com Sun Nov 21 19:51:37 2021 From: zjx001202 at gmail.com (Glavo) Date: Mon, 22 Nov 2021 03:51:37 +0800 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: You're talking about the way JNI works, not the way Panama Foreign Linker API works. All the problems you mentioned do not apply to Panama. The Foreign Linker API does not require you to write any native code, let alone compile native code. You only need to write pure Java code to implement it. Reducing the cost of native calls is also one of Panama's goals. I believe that the cost of calling native wrappers implemented through the Foreign Linker API is low enough in common Java running environments. Forgive me for not being familiar with these system APIs, so I can't provide you with an example implementation of this function here. I just copy an example given by the official here. I believe it can make you understand how the Foreign Linker API works: // 1. Find foreign function on the C library path MethodHandle radixSort = CLinker.getInstance().downcallHandle( CLinker.systemLookup().lookup("radixsort"), ...); // 2. Allocate on-heap memory to store four strings String[] javaStrings = { "mouse", "cat", "dog", "car" }; // 3. Allocate off-heap memory to store four pointers MemorySegment offHeap = MemorySegment.allocateNative( MemoryLayout.ofSequence(javaStrings.length, CLinker.C_POINTER), ...); // 4. Copy the strings from on-heap to off-heap for (int i = 0; i < javaStrings.length; i++) { // Allocate a string off-heap, then store a pointer to it MemorySegment cString = CLinker.toCString(javaStrings[i], newImplicitScope()); MemoryAccess.setAddressAtIndex(offHeap, i, cString.address()); } // 5. Sort the off-heap data by calling the foreign function radixSort.invoke(offHeap.address(), javaStrings.length, MemoryAddress.NULL, '\0'); // 6. Copy the (reordered) strings from off-heap to on-heap for (int i = 0; i < javaStrings.length; i++) { MemoryAddress cStringPtr = MemoryAccess.getAddressAtIndex(offHeap, i); javaStrings[i] = CLinker.toJavaStringRestricted(cStringPtr); } assert Arrays.equals(javaStrings, new String[] {"car", "cat", "dog", "mouse"}); // true It is recommended that you read JEP 419 in its entirety first to understand Panama, or take a look at the description of Panama FFI in this document: https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md Felix Cravic ?2021?11?22??? ??3:21??? > If it needs to be implemented through JNI, you may be right. > > However, for Panama, although we still need to use different codes for > different operating systems, all this can be implemented through pure java > code. > > Additional dependencies are unnecessary because these functions should be > part of the operating system. Because it only needs to be implemented in > Java code, it is not necessary to compile on multiple platforms. > > You will be able to declare the native methods in Java, but the native > library will need to be compiled for multiple platforms (and architecture) > > I don't understand why you should emphasize this. Does this bring any > additional problems? > > JNI comes with overhead. Correct me if I am wrong, but I believe JIT > compilers to work using an important number of stubs to allow > de-optimization which would not work well with the said overhead (the > alternative would be to move the work into the native code, but it doesn't > really serve the original goal of being java-only) > > This implementation does improve the difficulty of user code maintenance, > but this function itself is low-level, unsafe and platform related, and the > code using it is often platform related. > So I believe that when it is really needed, the problems caused by this > part are relatively insignificant, so I use the word "only". > > Cannot disagree here. Though Java would currently not be suited for a > project benefiting from such feature, which is a shame considering how > little API change it requires (feel free to correct me). The closest > alternative we have today is dynamic class loading, which is really good > for most use-case but not all. > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 20:04 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > Sorry, in the last sentence of that email, I wanted to say "just" instead > of "only". > > I am using Google translate to write email. Please forgive me for my > problems in grammar and words. > > Glavo ?2021?11?22??? ??3:00??? > > which would involve maintaining a native dependency and building it for > every potential platform > > > If it needs to be implemented through JNI, you may be right. > > However, for Panama, although we still need to use different codes for > different operating systems, all this can be implemented through pure java > code. > > Additional dependencies are unnecessary because these functions should be > part of the operating system. Because it only needs to be implemented in > Java code, it is not necessary to compile on multiple platforms. > > not to mention the fact that every execution will have to pass through > JNI/Linker API > > > I don't understand why you should emphasize this. Does this bring any > additional problems? > > I however disagree with the "just" > > This implementation does improve the difficulty of user code maintenance, > but this function itself is low-level, unsafe and platform related, and the > code using it is often platform related. > So I believe that when it is really needed, the problems caused by this > part are relatively insignificant, so I use the word "only". > > Felix Cravic ?2021?11?22??? ??2:41??? > > I agree that there are reasons why it could not have its place in Panama, > like OS limitations complicating the API design & it being another pretty > unsafe feature. > I however disagree with the "just", which would involve maintaining a > native dependency and building it for every potential platform, not to > mention the fact that every execution will have to pass through JNI/Linker > API. By that point I doubt that Java would be the right tool for the job, > or is it perhaps what you meant? > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 19:19 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > I don't think Panama should provide special support for it. > > To do this, you just need to create the binding of the relevant system API > (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) > with the foreign linker API and call it. > > Felix Cravic ?2021?11?22??? ??1:01??? > > Hello, I was wondering if there has ever been any discussion about > supporting allocation of executable memory (and then its execution). The > use cases I have in mind are emulation, very hot paths requiring > specialized assembly (which could still fallback to jvm bytecode if > unavailable), and a potential option to keep the whole application written > in a JVM language. > > I doubt that such addition would drastically change the API, perhaps some > concern about OS specific restrictions (e.g. write-xor-execute memory > protection), and platform not supporting JIT compilation at all (IOS, > potentially problematic for Graal & project Leyden) > > Discussion would be appreciated! > > From zjx001202 at gmail.com Sun Nov 21 20:30:27 2021 From: zjx001202 at gmail.com (Glavo) Date: Mon, 22 Nov 2021 04:30:27 +0800 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: > > Do you have any benchmark comparing JNI to the linker API? Last time I > checked those were similar and the JEP mentions "similar performance". I am > aware of how the API works, I am however still not convinced that it fixes > my previous points. > At this stage, the performance of Panama will not be higher than that of JNI, because its back end is still based on JNI, so it should have similar performance. At present, Panama is still some distance away from maturity, but it leaves more room for optimization for the JVM. Please wait patiently for it to focus on optimizing performance after it matures in function. Sure you can implement the Java side solely in Java, but you will obviously > still need to compile the native library for multiple platforms & > architectures. I emphasize here again that Panama is different from JNI, There is no need to compile the native library. All we need is: 1. Through SymbolLookup::lookup, find the symbols of system API in the system library; 2. Through CLinker::downcallHandle, generate MethodHandle corresponding to the system API; 3. Call it. This is completely implemented in Java code, and there is no need to use native code, let alone compile native code. Felix Cravic ?2021?11?22??? ??3:58??? > Do you have any benchmark comparing JNI to the linker API? Last time I > checked those were similar and the JEP mentions "similar performance". I am > aware of how the API works, I am however still not convinced that it fixes > my previous points. > > Sure you can implement the Java side solely in Java, but you will > obviously still need to compile the native library for multiple platforms & > architectures. > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 20:51 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > You're talking about the way JNI works, not the way Panama Foreign Linker > API works. All the problems you mentioned do not apply to Panama. > The Foreign Linker API does not require you to write any native code, let > alone compile native code. You only need to write pure Java code to > implement it. > > Reducing the cost of native calls is also one of Panama's goals. I believe > that the cost of calling native wrappers implemented through the Foreign > Linker API is low enough in common Java running environments. > > Forgive me for not being familiar with these system APIs, so I can't > provide you with an example implementation of this function here. > I just copy an example given by the official here. I believe it can make > you understand how the Foreign Linker API works: > > // 1. Find foreign function on the C library path > MethodHandle radixSort = CLinker.getInstance().downcallHandle( > CLinker.systemLookup().lookup("radixsort"), > ...); > // 2. Allocate on-heap memory to store four strings > String[] javaStrings = { "mouse", "cat", "dog", "car" }; > // 3. Allocate off-heap memory to store four pointers > MemorySegment offHeap = MemorySegment.allocateNative( > MemoryLayout.ofSequence(javaStrings.length, > CLinker.C_POINTER), > ...); > // 4. Copy the strings from on-heap to off-heap > for (int i = 0; i < javaStrings.length; i++) { > // Allocate a string off-heap, then store a pointer to it > MemorySegment cString = CLinker.toCString(javaStrings[i], > newImplicitScope()); > MemoryAccess.setAddressAtIndex(offHeap, i, cString.address()); > } > // 5. Sort the off-heap data by calling the foreign function > radixSort.invoke(offHeap.address(), javaStrings.length, > MemoryAddress.NULL, '\0'); > // 6. Copy the (reordered) strings from off-heap to on-heap > for (int i = 0; i < javaStrings.length; i++) { > MemoryAddress cStringPtr = MemoryAccess.getAddressAtIndex(offHeap, i); > javaStrings[i] = CLinker.toJavaStringRestricted(cStringPtr); > } > assert Arrays.equals(javaStrings, new String[] {"car", "cat", "dog", > "mouse"}); // true > > > It is recommended that you read JEP 419 in its entirety first to > understand Panama, or take a look at the description of Panama FFI in this > document: > > > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md > > > > > > > Felix Cravic ?2021?11?22??? ??3:21??? > > If it needs to be implemented through JNI, you may be right. > > However, for Panama, although we still need to use different codes for > different operating systems, all this can be implemented through pure java > code. > > Additional dependencies are unnecessary because these functions should be > part of the operating system. Because it only needs to be implemented in > Java code, it is not necessary to compile on multiple platforms. > > You will be able to declare the native methods in Java, but the native > library will need to be compiled for multiple platforms (and architecture) > > I don't understand why you should emphasize this. Does this bring any > additional problems? > > JNI comes with overhead. Correct me if I am wrong, but I believe JIT > compilers to work using an important number of stubs to allow > de-optimization which would not work well with the said overhead (the > alternative would be to move the work into the native code, but it doesn't > really serve the original goal of being java-only) > > This implementation does improve the difficulty of user code maintenance, > but this function itself is low-level, unsafe and platform related, and the > code using it is often platform related. > So I believe that when it is really needed, the problems caused by this > part are relatively insignificant, so I use the word "only". > > Cannot disagree here. Though Java would currently not be suited for a > project benefiting from such feature, which is a shame considering how > little API change it requires (feel free to correct me). The closest > alternative we have today is dynamic class loading, which is really good > for most use-case but not all. > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 20:04 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > Sorry, in the last sentence of that email, I wanted to say "just" instead > of "only". > > I am using Google translate to write email. Please forgive me for my > problems in grammar and words. > > Glavo ?2021?11?22??? ??3:00??? > > which would involve maintaining a native dependency and building it for > every potential platform > > > If it needs to be implemented through JNI, you may be right. > > However, for Panama, although we still need to use different codes for > different operating systems, all this can be implemented through pure java > code. > > Additional dependencies are unnecessary because these functions should be > part of the operating system. Because it only needs to be implemented in > Java code, it is not necessary to compile on multiple platforms. > > not to mention the fact that every execution will have to pass through > JNI/Linker API > > > I don't understand why you should emphasize this. Does this bring any > additional problems? > > I however disagree with the "just" > > This implementation does improve the difficulty of user code maintenance, > but this function itself is low-level, unsafe and platform related, and the > code using it is often platform related. > So I believe that when it is really needed, the problems caused by this > part are relatively insignificant, so I use the word "only". > > Felix Cravic ?2021?11?22??? ??2:41??? > > I agree that there are reasons why it could not have its place in Panama, > like OS limitations complicating the API design & it being another pretty > unsafe feature. > I however disagree with the "just", which would involve maintaining a > native dependency and building it for every potential platform, not to > mention the fact that every execution will have to pass through JNI/Linker > API. By that point I doubt that Java would be the right tool for the job, > or is it perhaps what you meant? > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 19:19 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > I don't think Panama should provide special support for it. > > To do this, you just need to create the binding of the relevant system API > (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) > with the foreign linker API and call it. > > Felix Cravic ?2021?11?22??? ??1:01??? > > Hello, I was wondering if there has ever been any discussion about > supporting allocation of executable memory (and then its execution). The > use cases I have in mind are emulation, very hot paths requiring > specialized assembly (which could still fallback to jvm bytecode if > unavailable), and a potential option to keep the whole application written > in a JVM language. > > I doubt that such addition would drastically change the API, perhaps some > concern about OS specific restrictions (e.g. write-xor-execute memory > protection), and platform not supporting JIT compilation at all (IOS, > potentially problematic for Graal & project Leyden) > > Discussion would be appreciated! > > From zjx001202 at gmail.com Sun Nov 21 20:46:20 2021 From: zjx001202 at gmail.com (Glavo) Date: Mon, 22 Nov 2021 04:46:20 +0800 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: You can generate MethodHandle from the MemoryAddress/MemorySegment using CLinker::downcallHandle, and then call it. Felix Cravic ?2021?11?22??? ??4:36??? > I emphasize here again that Panama is different from JNI, There is no > need to compile the native library. > All we need is: > > 1. Through SymbolLookup::lookup, find the symbols of system API in > the system library; > 2. Through CLinker::downcallHandle, generate MethodHandle > corresponding to the system API; > 3. Call it. > > This is completely implemented in Java code, and there is no need to use > native code, let alone compile native code. > > ?Indeed I guess that it works for the allocation phase, how would you run > the code given an executable memory address? > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 21:30 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > > Do you have any benchmark comparing JNI to the linker API? Last time I > checked those were similar and the JEP mentions "similar performance". I am > aware of how the API works, I am however still not convinced that it fixes > my previous points. > > > At this stage, the performance of Panama will not be higher than that of > JNI, because its back end is still based on JNI, so it should have similar > performance. > At present, Panama is still some distance away from maturity, but it > leaves more room for optimization for the JVM. Please wait patiently for it > to focus on optimizing performance after it matures in function. > > Sure you can implement the Java side solely in Java, but you will > obviously still need to compile the native library for multiple platforms & > architectures. > > > I emphasize here again that Panama is different from JNI, There is no > need to compile the native library. > All we need is: > > 1. Through SymbolLookup::lookup, find the symbols of system API in > the system library; > 2. Through CLinker::downcallHandle, generate MethodHandle > corresponding to the system API; > 3. Call it. > > This is completely implemented in Java code, and there is no need to use > native code, let alone compile native code. > > Felix Cravic ?2021?11?22??? ??3:58??? > > Do you have any benchmark comparing JNI to the linker API? Last time I > checked those were similar and the JEP mentions "similar performance". I am > aware of how the API works, I am however still not convinced that it fixes > my previous points. > > Sure you can implement the Java side solely in Java, but you will > obviously still need to compile the native library for multiple platforms & > architectures. > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 20:51 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > You're talking about the way JNI works, not the way Panama Foreign Linker > API works. All the problems you mentioned do not apply to Panama. > The Foreign Linker API does not require you to write any native code, let > alone compile native code. You only need to write pure Java code to > implement it. > > Reducing the cost of native calls is also one of Panama's goals. I believe > that the cost of calling native wrappers implemented through the Foreign > Linker API is low enough in common Java running environments. > > Forgive me for not being familiar with these system APIs, so I can't > provide you with an example implementation of this function here. > I just copy an example given by the official here. I believe it can make > you understand how the Foreign Linker API works: > > // 1. Find foreign function on the C library path > MethodHandle radixSort = CLinker.getInstance().downcallHandle( > CLinker.systemLookup().lookup("radixsort"), > ...); > // 2. Allocate on-heap memory to store four strings > String[] javaStrings = { "mouse", "cat", "dog", "car" }; > // 3. Allocate off-heap memory to store four pointers > MemorySegment offHeap = MemorySegment.allocateNative( > MemoryLayout.ofSequence(javaStrings.length, > CLinker.C_POINTER), > ...); > // 4. Copy the strings from on-heap to off-heap > for (int i = 0; i < javaStrings.length; i++) { > // Allocate a string off-heap, then store a pointer to it > MemorySegment cString = CLinker.toCString(javaStrings[i], > newImplicitScope()); > MemoryAccess.setAddressAtIndex(offHeap, i, cString.address()); > } > // 5. Sort the off-heap data by calling the foreign function > radixSort.invoke(offHeap.address(), javaStrings.length, > MemoryAddress.NULL, '\0'); > // 6. Copy the (reordered) strings from off-heap to on-heap > for (int i = 0; i < javaStrings.length; i++) { > MemoryAddress cStringPtr = MemoryAccess.getAddressAtIndex(offHeap, i); > javaStrings[i] = CLinker.toJavaStringRestricted(cStringPtr); > } > assert Arrays.equals(javaStrings, new String[] {"car", "cat", "dog", > "mouse"}); // true > > > It is recommended that you read JEP 419 in its entirety first to > understand Panama, or take a look at the description of Panama FFI in this > document: > > > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md > > > > > > > Felix Cravic ?2021?11?22??? ??3:21??? > > If it needs to be implemented through JNI, you may be right. > > However, for Panama, although we still need to use different codes for > different operating systems, all this can be implemented through pure java > code. > > Additional dependencies are unnecessary because these functions should be > part of the operating system. Because it only needs to be implemented in > Java code, it is not necessary to compile on multiple platforms. > > You will be able to declare the native methods in Java, but the native > library will need to be compiled for multiple platforms (and architecture) > > I don't understand why you should emphasize this. Does this bring any > additional problems? > > JNI comes with overhead. Correct me if I am wrong, but I believe JIT > compilers to work using an important number of stubs to allow > de-optimization which would not work well with the said overhead (the > alternative would be to move the work into the native code, but it doesn't > really serve the original goal of being java-only) > > This implementation does improve the difficulty of user code maintenance, > but this function itself is low-level, unsafe and platform related, and the > code using it is often platform related. > So I believe that when it is really needed, the problems caused by this > part are relatively insignificant, so I use the word "only". > > Cannot disagree here. Though Java would currently not be suited for a > project benefiting from such feature, which is a shame considering how > little API change it requires (feel free to correct me). The closest > alternative we have today is dynamic class loading, which is really good > for most use-case but not all. > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 20:04 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > Sorry, in the last sentence of that email, I wanted to say "just" instead > of "only". > > I am using Google translate to write email. Please forgive me for my > problems in grammar and words. > > Glavo ?2021?11?22??? ??3:00??? > > which would involve maintaining a native dependency and building it for > every potential platform > > > If it needs to be implemented through JNI, you may be right. > > However, for Panama, although we still need to use different codes for > different operating systems, all this can be implemented through pure java > code. > > Additional dependencies are unnecessary because these functions should be > part of the operating system. Because it only needs to be implemented in > Java code, it is not necessary to compile on multiple platforms. > > not to mention the fact that every execution will have to pass through > JNI/Linker API > > > I don't understand why you should emphasize this. Does this bring any > additional problems? > > I however disagree with the "just" > > This implementation does improve the difficulty of user code maintenance, > but this function itself is low-level, unsafe and platform related, and the > code using it is often platform related. > So I believe that when it is really needed, the problems caused by this > part are relatively insignificant, so I use the word "only". > > Felix Cravic ?2021?11?22??? ??2:41??? > > I agree that there are reasons why it could not have its place in Panama, > like OS limitations complicating the API design & it being another pretty > unsafe feature. > I however disagree with the "just", which would involve maintaining a > native dependency and building it for every potential platform, not to > mention the fact that every execution will have to pass through JNI/Linker > API. By that point I doubt that Java would be the right tool for the job, > or is it perhaps what you meant? > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 19:19 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > I don't think Panama should provide special support for it. > > To do this, you just need to create the binding of the relevant system API > (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) > with the foreign linker API and call it. > > Felix Cravic ?2021?11?22??? ??1:01??? > > Hello, I was wondering if there has ever been any discussion about > supporting allocation of executable memory (and then its execution). The > use cases I have in mind are emulation, very hot paths requiring > specialized assembly (which could still fallback to jvm bytecode if > unavailable), and a potential option to keep the whole application written > in a JVM language. > > I doubt that such addition would drastically change the API, perhaps some > concern about OS specific restrictions (e.g. write-xor-execute memory > protection), and platform not supporting JIT compilation at all (IOS, > potentially problematic for Graal & project Leyden) > > Discussion would be appreciated! > > From zjx001202 at gmail.com Sun Nov 21 22:11:31 2021 From: zjx001202 at gmail.com (Glavo) Date: Mon, 22 Nov 2021 06:11:31 +0800 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: Hey, I implemented a JIT demo with Panama: https://gist.github.com/Glavo/aabbac7f206c56beeacd711c4726e260 It runs on the windows AMD64 platform and requires Java 17. I am not familiar with JIT, so I implemented it with reference to the C++ code here: https://stackoverflow.com/a/40937610/7659948 If there is any problem with it, please let me know. Felix Cravic ?2021?11?22??? ??4:36??? > I emphasize here again that Panama is different from JNI, There is no > need to compile the native library. > All we need is: > > 1. Through SymbolLookup::lookup, find the symbols of system API in > the system library; > 2. Through CLinker::downcallHandle, generate MethodHandle > corresponding to the system API; > 3. Call it. > > This is completely implemented in Java code, and there is no need to use > native code, let alone compile native code. > > Indeed I guess that it works for the allocation phase, how would you run > the code given an executable memory address? > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 21:30 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > > Do you have any benchmark comparing JNI to the linker API? Last time I > checked those were similar and the JEP mentions "similar performance". I am > aware of how the API works, I am however still not convinced that it fixes > my previous points. > > > At this stage, the performance of Panama will not be higher than that of > JNI, because its back end is still based on JNI, so it should have similar > performance. > At present, Panama is still some distance away from maturity, but it > leaves more room for optimization for the JVM. Please wait patiently for it > to focus on optimizing performance after it matures in function. > > Sure you can implement the Java side solely in Java, but you will > obviously still need to compile the native library for multiple platforms & > architectures. > > > I emphasize here again that Panama is different from JNI, There is no > need to compile the native library. > All we need is: > > 1. Through SymbolLookup::lookup, find the symbols of system API in > the system library; > 2. Through CLinker::downcallHandle, generate MethodHandle > corresponding to the system API; > 3. Call it. > > This is completely implemented in Java code, and there is no need to use > native code, let alone compile native code. > > Felix Cravic ?2021?11?22??? ??3:58??? > > Do you have any benchmark comparing JNI to the linker API? Last time I > checked those were similar and the JEP mentions "similar performance". I am > aware of how the API works, I am however still not convinced that it fixes > my previous points. > > Sure you can implement the Java side solely in Java, but you will > obviously still need to compile the native library for multiple platforms & > architectures. > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 20:51 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > You're talking about the way JNI works, not the way Panama Foreign Linker > API works. All the problems you mentioned do not apply to Panama. > The Foreign Linker API does not require you to write any native code, let > alone compile native code. You only need to write pure Java code to > implement it. > > Reducing the cost of native calls is also one of Panama's goals. I believe > that the cost of calling native wrappers implemented through the Foreign > Linker API is low enough in common Java running environments. > > Forgive me for not being familiar with these system APIs, so I can't > provide you with an example implementation of this function here. > I just copy an example given by the official here. I believe it can make > you understand how the Foreign Linker API works: > > // 1. Find foreign function on the C library path > MethodHandle radixSort = CLinker.getInstance().downcallHandle( > CLinker.systemLookup().lookup("radixsort"), > ...); > // 2. Allocate on-heap memory to store four strings > String[] javaStrings = { "mouse", "cat", "dog", "car" }; > // 3. Allocate off-heap memory to store four pointers > MemorySegment offHeap = MemorySegment.allocateNative( > MemoryLayout.ofSequence(javaStrings.length, > CLinker.C_POINTER), > ...); > // 4. Copy the strings from on-heap to off-heap > for (int i = 0; i < javaStrings.length; i++) { > // Allocate a string off-heap, then store a pointer to it > MemorySegment cString = CLinker.toCString(javaStrings[i], > newImplicitScope()); > MemoryAccess.setAddressAtIndex(offHeap, i, cString.address()); > } > // 5. Sort the off-heap data by calling the foreign function > radixSort.invoke(offHeap.address(), javaStrings.length, > MemoryAddress.NULL, '\0'); > // 6. Copy the (reordered) strings from off-heap to on-heap > for (int i = 0; i < javaStrings.length; i++) { > MemoryAddress cStringPtr = MemoryAccess.getAddressAtIndex(offHeap, i); > javaStrings[i] = CLinker.toJavaStringRestricted(cStringPtr); > } > assert Arrays.equals(javaStrings, new String[] {"car", "cat", "dog", > "mouse"}); // true > > > It is recommended that you read JEP 419 in its entirety first to > understand Panama, or take a look at the description of Panama FFI in this > document: > > > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md > > > > > > > Felix Cravic ?2021?11?22??? ??3:21??? > > If it needs to be implemented through JNI, you may be right. > > However, for Panama, although we still need to use different codes for > different operating systems, all this can be implemented through pure java > code. > > Additional dependencies are unnecessary because these functions should be > part of the operating system. Because it only needs to be implemented in > Java code, it is not necessary to compile on multiple platforms. > > You will be able to declare the native methods in Java, but the native > library will need to be compiled for multiple platforms (and architecture) > > I don't understand why you should emphasize this. Does this bring any > additional problems? > > JNI comes with overhead. Correct me if I am wrong, but I believe JIT > compilers to work using an important number of stubs to allow > de-optimization which would not work well with the said overhead (the > alternative would be to move the work into the native code, but it doesn't > really serve the original goal of being java-only) > > This implementation does improve the difficulty of user code maintenance, > but this function itself is low-level, unsafe and platform related, and the > code using it is often platform related. > So I believe that when it is really needed, the problems caused by this > part are relatively insignificant, so I use the word "only". > > Cannot disagree here. Though Java would currently not be suited for a > project benefiting from such feature, which is a shame considering how > little API change it requires (feel free to correct me). The closest > alternative we have today is dynamic class loading, which is really good > for most use-case but not all. > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 20:04 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > Sorry, in the last sentence of that email, I wanted to say "just" instead > of "only". > > I am using Google translate to write email. Please forgive me for my > problems in grammar and words. > > Glavo ?2021?11?22??? ??3:00??? > > which would involve maintaining a native dependency and building it for > every potential platform > > > If it needs to be implemented through JNI, you may be right. > > However, for Panama, although we still need to use different codes for > different operating systems, all this can be implemented through pure java > code. > > Additional dependencies are unnecessary because these functions should be > part of the operating system. Because it only needs to be implemented in > Java code, it is not necessary to compile on multiple platforms. > > not to mention the fact that every execution will have to pass through > JNI/Linker API > > > I don't understand why you should emphasize this. Does this bring any > additional problems? > > I however disagree with the "just" > > This implementation does improve the difficulty of user code maintenance, > but this function itself is low-level, unsafe and platform related, and the > code using it is often platform related. > So I believe that when it is really needed, the problems caused by this > part are relatively insignificant, so I use the word "only". > > Felix Cravic ?2021?11?22??? ??2:41??? > > I agree that there are reasons why it could not have its place in Panama, > like OS limitations complicating the API design & it being another pretty > unsafe feature. > I however disagree with the "just", which would involve maintaining a > native dependency and building it for every potential platform, not to > mention the fact that every execution will have to pass through JNI/Linker > API. By that point I doubt that Java would be the right tool for the job, > or is it perhaps what you meant? > ------------------------------ > *De :* Glavo > *Envoy? :* dimanche 21 novembre 2021 19:19 > *? :* Felix Cravic > *Cc :* panama-dev at openjdk.java.net > *Objet :* Re: Support for allocation of executable memory > > I don't think Panama should provide special support for it. > > To do this, you just need to create the binding of the relevant system API > (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) > with the foreign linker API and call it. > > Felix Cravic ?2021?11?22??? ??1:01??? > > Hello, I was wondering if there has ever been any discussion about > supporting allocation of executable memory (and then its execution). The > use cases I have in mind are emulation, very hot paths requiring > specialized assembly (which could still fallback to jvm bytecode if > unavailable), and a potential option to keep the whole application written > in a JVM language. > > I doubt that such addition would drastically change the API, perhaps some > concern about OS specific restrictions (e.g. write-xor-execute memory > protection), and platform not supporting JIT compilation at all (IOS, > potentially problematic for Graal & project Leyden) > > Discussion would be appreciated! > > From maurizio.cimadamore at oracle.com Mon Nov 22 10:41:25 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 22 Nov 2021 10:41:25 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> <-QTuGDa0nmGTEPQ9e09MZxEU9ozr5M4FRwmJvR330RmH9yJsaRFWk0Iat-WWquO9MFmpmJst0bsK-JTJfjM2cDsdbVl4z9QjcRKqkUftG6U=@protonmail.com> Message-ID: <5be0b498-8606-0ed9-0b7a-b07056098f0a@oracle.com> Hi Martin, we used to have a check similar to the one you describe in an earlier version of jextract (e.g. when `-l` was specified, we would check that functions/global vars were emitted in said libs). We can probably re-add such a check. Maurizio On 21/11/2021 17:39, Martin Pernollet wrote: > Hi, > > The UnsatisfiedLinkError was triggered while invoking a method relying on a null method handle. > > When invoking jextract, I provided an include dir with multiple header files (usr/include/GL) but an incomplete list of libraries. The code is generated correctly and the user of this generated code don't see any problem at compile time. However, when running the program, glut_h will only map a subset of the generated method handles to the native libs. > > It would be convenient to get warnings about it when the program starts. Would you recommend a way to iterate over all generated method handles to check those that are null? > > /usr/lib/jvm/jdk-17-panama/bin/jextract -d ./src/main/java/ --source -t opengl.ubuntu.v20 \ > -lGL \ > -l/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 \ > -l/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1 \ << that one was missing > -I /usr/include/GL \ > -C-F/usr/include/GL \ > /usr/include/GL/glut.h > > > public class glut_h extends glut_h_6 { > > static { > System.loadLibrary("GL"); > System.load("/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0"); > System.load("/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1"); // fixing jextract lib list let glut_h map the metod handle to the native libs > } > > Cheers, > > Martin > > ??????? Original Message ??????? > > Le lundi 15 novembre 2021 ? 11:43, Maurizio Cimadamore a ?crit : > >> Hi, >> >> from the top of my head, this looks like an exception thrown while you >> >> are executing an upcall. And it also looks like you are missing some of >> >> the latest patches which will generate a "normal" stack trace. So you >> >> only see the exception name (UnsatisfiedLink). >> >> As a general rule, if an exception occurs when an upcall is executing, >> >> only option is to exit the Java program, so that we don't leave the >> >> native code in a potentially bad state. >> >> But more recent releases of the linker API do a better job at presenting >> >> this as an "exception" (although one that cannot be caught) rather than >> >> a blunt crash. >> >> If you can't update to a newer build, I'd look into all upcall code, >> >> looking for all pieces of code which might do System.load/loadLibrary. >> >> Maurizio >> >> On 15/11/2021 07:33, Martin Pernollet wrote: >> >>> Hi, >>> >>> I am now on Ubuntu. The original teapot sample is working (just >>> >>> required to change glutDisplayFunc$func to glutDisplayFunc$callback). >>> >>> I got an UnstasfiedLinkException with other programs. I wonder if you >>> >>> have a suggestion to help me understand my mistake? LDD command does >>> >>> not help. Like for the NPE, we lack a bit of info for debugging. >>> >>> Console says >>> >>> Uncaught exception: >>> >>> java.lang.UnsatisfiedLinkError >>> >>> {0x0000000091ac9b58} - klass: 'java/lang/UnsatisfiedLinkError' >>> >>> A fatal error has been detected by the Java Runtime Environment: >>> ================================================================ >>> >>> #? Internal Error (universalUpcallHandler.cpp:113), pid=33668, tid=33677 >>> >>> #? Error: ShouldNotReachHere() >>> >>> Core dump says (see attached the complete core dump file) >>> >>> Current thread (0x00007f5d580268c0):? JavaThread "main" >>> >>> [_thread_in_Java, id=35593, stack(0x00007f5d5f59e000,0x00007f5d5f69f000)] >>> >>> Stack: [0x00007f5d5f59e000,0x00007f5d5f69f000], >>> >>> sp=0x00007f5d5f69c8b0,? free space=1018k >>> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>> >>> C=native code) >>> >>> V? [libjvm.so+0xd993a3] >>> >>> ProgrammableUpcallHandler::handle_uncaught_exception(oopDesc*)+0x43 >>> >>> v? ~BufferBlob::panama_upcall_stub >>> >>> C? [libglut.so.3.9.0+0x20895]? glutMainLoopEvent+0x2a5 >>> >>> Register to memory mapping: >>> >>> RAX=0x00007f5d60cc4000 points into unknown readable memory: >>> >>> 0x0000000000000058 | 58 00 00 00 00 00 00 00 >>> >>> RBX=0x00007f5d4184556a is at code_begin+842 in >>> >>> [CodeBlob (0x00007f5d41845190)] >>> >>> Framesize: 0 >>> >>> BufferBlob (0x00007f5d41845190) used for panama_upcall_stub >>> >>> RCX=0x000000000000000a is an unknown value >>> >>> RDX=0x0 is NULL >>> >>> RSP=0x00007f5d5f69c8b0 is pointing into the stack for thread: >>> >>> 0x00007f5d580268c0 >>> >>> RBP=0x00007f5d5f69c8c0 is pointing into the stack for thread: >>> >>> 0x00007f5d580268c0 >>> >>> RSI=0x0000000000000071 is an unknown value >>> >>> RDI=0x00007f5d606f6108: in >>> >>> /usr/lib/jvm/jdk-17-panama/lib/server/libjvm.so at 0x00007f5d5f7f9000 >>> >>> R8 =0x0 is NULL >>> >>> R9 =0x00007f5d5f69c8a0 is pointing into the stack for thread: >>> >>> 0x00007f5d580268c0 >>> >>> R10=0x0 is NULL >>> >>> R11=0x0 is NULL >>> >>> R12=0x0000000091d82828 is an oop: java.lang.UnsatisfiedLinkError >>> >>> {0x0000000091d82828} - klass: 'java/lang/UnsatisfiedLinkError' >>> >>> R13=0x00007f5d1c42fbdc is pointing into metadata >>> >>> R14=0x00007f5d5f69c8c8 is pointing into the stack for thread: >>> >>> 0x00007f5d580268c0 >>> >>> R15=0x00007f5d580268c0 is a thread >>> >>> I verified with LDD if the lib I am linking to has dependencies >>> >>> problem but it seams to be ok. >>> >>> ldd --verbose /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 >>> >>> linux-vdso.so.1 (0x00007ffc37dcd000) >>> >>> libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007effdf322000) >>> >>> libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007effdf1e5000) >>> >>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007effdf096000) >>> >>> libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007effdf084000) >>> >>> libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 >>> >>> (0x00007effdf07d000) >>> >>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007effdee8b000) >>> >>> libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 >>> >>> (0x00007effdedd1000) >>> >>> libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007effded9d000) >>> >>> libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007effded73000) >>> >>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007effded6d000) >>> >>> /lib64/ld-linux-x86-64.so.2 (0x00007effdf608000) >>> >>> libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007effded58000) >>> >>> libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007effded50000) >>> >>> libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007effded48000) >>> >>> libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007effded2e000) >>> >>> Version information: >>> >>> /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0: >>> >>> libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6 >>> >>> libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libGL.so.1: >>> >>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libX11.so.6: >>> >>> libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 >>> >>> libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.26) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libm.so.6: >>> >>> ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libXi.so.6: >>> >>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libXxf86vm.so.1: >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libc.so.6: >>> >>> ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 >>> >>> ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 >>> >>> /lib/x86_64-linux-gnu/libGLdispatch.so.0: >>> >>> libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 >>> >>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libGLX.so.0: >>> >>> libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 >>> >>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libxcb.so.1: >>> >>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libdl.so.2: >>> >>> ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 >>> >>> libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libXext.so.6: >>> >>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libXau.so.6: >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libXdmcp.so.6: >>> >>> libbsd.so.0 (LIBBSD_0.2) => /lib/x86_64-linux-gnu/libbsd.so.0 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> /lib/x86_64-linux-gnu/libbsd.so.0: >>> >>> libc.so.6 (GLIBC_2.25) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.16) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.8) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>> >>> libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 From maurizio.cimadamore at oracle.com Mon Nov 22 10:59:37 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 22 Nov 2021 10:59:37 +0000 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: Hi Felix, as Glavo mentions, changing the memory protection of a memory segment shouldn't be too hard using ad-hoc method handle calls. These system calls should be available in the default linker lookup, so you should not need any extra dependencies (unlike with JNI where you would still require a custom shared lib). This question reminds me of other similar questions around adding more support for OS-specific flags around mapped memory segments. I believe both are cases where the linker API can be used to use OS-specific functionalities. Also, for some mysterious reasons I can't see some parts of the discussion - e.g. I see Glavo answering questions re. performance, but I do not see said questions. The very high-level summary performance-wise is that, for downcalls (Java->Native) performance should be similar to JNI, whereas for upcalls (Native->Java), Panama should be a bit faster (2x to 3x, depending on the benchmark). That said, even in downcall contexts, the comparison wildly depends on what you are doing. For instance, the fact that Panama allows you to specify a custom segment allocator for pretty much every operation which generates native memory, if used wisely, can lead to further speedup. One example is string conversion: in JNI string conversion is hardwired to use malloc to allocate the native string. In Panama you can pick whatever allocation scheme you want. Since Java->Native string conversion is mostly allocation bound, you can get quite a big speedup just by using a more performant allocator (e.g. an arena). At a later point we might investigate other optimization strategies; such as eliminating Java/native state transitions for back to back calls, or ability to pin regions of heap memory (so that it can be passed to native code directly). But those are trickier to get right (and can negatively affect performance of the GC subsystem), so we will proceed with care. Maurizio On 21/11/2021 07:33, Felix Cravic wrote: > Hello, I was wondering if there has ever been any discussion about supporting allocation of executable memory (and then its execution). The use cases I have in mind are emulation, very hot paths requiring specialized assembly (which could still fallback to jvm bytecode if unavailable), and a potential option to keep the whole application written in a JVM language. > > I doubt that such addition would drastically change the API, perhaps some concern about OS specific restrictions (e.g. write-xor-execute memory protection), and platform not supporting JIT compilation at all (IOS, potentially problematic for Graal & project Leyden) > > Discussion would be appreciated! From martin.pernollet at protonmail.com Mon Nov 22 12:08:25 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Mon, 22 Nov 2021 12:08:25 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: <5be0b498-8606-0ed9-0b7a-b07056098f0a@oracle.com> References: <8bc27ac0-013e-f76a-4496-77229cbbc0b1@oracle.com> <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> <-QTuGDa0nmGTEPQ9e09MZxEU9ozr5M4FRwmJvR330RmH9yJsaRFWk0Iat-WWquO9MFmpmJst0bsK-JTJfjM2cDsdbVl4z9QjcRKqkUftG6U=@protonmail.com> <5be0b498-8606-0ed9-0b7a-b07056098f0a@oracle.com> Message-ID: Hi Maurizio, Maybe this would be more handy to run this from the program using the binding : providing the libs to JExtract has the drawback to tidying the generated library to the developer lib path. In the future I woule like not use the -l option to prevent JExtract from generating the System.load and System.loadLibrary, and write this lib loading code on the user side. Example use case that I got working : I generated bindings from a Mac 11.4 computer which has the lib at a given path /a/b/c. I ran from a Mac 10.15 and noticed it works perfectly by just modifying the path to the GL libs at /d/e/f. If I was wrong entering /d/e/g at runtime, I would like to detect unmapped functions. Cheers Sent with ProtonMail Secure Email. ??????? Original Message ??????? Le lundi 22 novembre 2021 ? 11:41, Maurizio Cimadamore a ?crit : > Hi Martin, > > we used to have a check similar to the one you describe in an earlier > > version of jextract (e.g. when `-l` was specified, we would check that > > functions/global vars were emitted in said libs). We can probably re-add > > such a check. > > Maurizio > > On 21/11/2021 17:39, Martin Pernollet wrote: > > > Hi, > > > > The UnsatisfiedLinkError was triggered while invoking a method relying on a null method handle. > > > > When invoking jextract, I provided an include dir with multiple header files (usr/include/GL) but an incomplete list of libraries. The code is generated correctly and the user of this generated code don't see any problem at compile time. However, when running the program, glut_h will only map a subset of the generated method handles to the native libs. > > > > It would be convenient to get warnings about it when the program starts. Would you recommend a way to iterate over all generated method handles to check those that are null? > > > > /usr/lib/jvm/jdk-17-panama/bin/jextract -d ./src/main/java/ --source -t opengl.ubuntu.v20 \ > > > > -lGL \ > > > > -l/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 \ > > > > -l/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1 \ << that one was missing > > > > -I /usr/include/GL \ > > > > -C-F/usr/include/GL \ > > > > /usr/include/GL/glut.h > > > > public class glut_h extends glut_h_6 { > > > > static { > > System.loadLibrary("GL"); > > System.load("/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0"); > > System.load("/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1"); // fixing jextract lib list let glut_h map the metod handle to the native libs > > } > > > > > > Cheers, > > > > Martin > > > > ??????? Original Message ??????? > > > > Le lundi 15 novembre 2021 ? 11:43, Maurizio Cimadamore maurizio.cimadamore at oracle.com a ?crit : > > > > > Hi, > > > > > > from the top of my head, this looks like an exception thrown while you > > > > > > are executing an upcall. And it also looks like you are missing some of > > > > > > the latest patches which will generate a "normal" stack trace. So you > > > > > > only see the exception name (UnsatisfiedLink). > > > > > > As a general rule, if an exception occurs when an upcall is executing, > > > > > > only option is to exit the Java program, so that we don't leave the > > > > > > native code in a potentially bad state. > > > > > > But more recent releases of the linker API do a better job at presenting > > > > > > this as an "exception" (although one that cannot be caught) rather than > > > > > > a blunt crash. > > > > > > If you can't update to a newer build, I'd look into all upcall code, > > > > > > looking for all pieces of code which might do System.load/loadLibrary. > > > > > > Maurizio > > > > > > On 15/11/2021 07:33, Martin Pernollet wrote: > > > > > > > Hi, > > > > > > > > I am now on Ubuntu. The original teapot sample is working (just > > > > > > > > required to change glutDisplayFunc$func to glutDisplayFunc$callback). > > > > > > > > I got an UnstasfiedLinkException with other programs. I wonder if you > > > > > > > > have a suggestion to help me understand my mistake? LDD command does > > > > > > > > not help. Like for the NPE, we lack a bit of info for debugging. > > > > > > > > Console says > > > > > > > > Uncaught exception: > > > > > > > > java.lang.UnsatisfiedLinkError > > > > > > > > {0x0000000091ac9b58} - klass: 'java/lang/UnsatisfiedLinkError' > > > > > > > > A fatal error has been detected by the Java Runtime Environment: > > > > ================================================================ > > > > > > > > #? Internal Error (universalUpcallHandler.cpp:113), pid=33668, tid=33677 > > > > > > > > #? Error: ShouldNotReachHere() > > > > > > > > Core dump says (see attached the complete core dump file) > > > > > > > > Current thread (0x00007f5d580268c0):? JavaThread "main" > > > > > > > > [_thread_in_Java, id=35593, stack(0x00007f5d5f59e000,0x00007f5d5f69f000)] > > > > > > > > Stack: [0x00007f5d5f59e000,0x00007f5d5f69f000], > > > > > > > > sp=0x00007f5d5f69c8b0,? free space=1018k > > > > > > > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > > > > > > > > C=native code) > > > > > > > > V? [libjvm.so+0xd993a3] > > > > > > > > ProgrammableUpcallHandler::handle_uncaught_exception(oopDesc*)+0x43 > > > > > > > > v? ~BufferBlob::panama_upcall_stub > > > > > > > > C? [libglut.so.3.9.0+0x20895]? glutMainLoopEvent+0x2a5 > > > > > > > > Register to memory mapping: > > > > > > > > RAX=0x00007f5d60cc4000 points into unknown readable memory: > > > > > > > > 0x0000000000000058 | 58 00 00 00 00 00 00 00 > > > > > > > > RBX=0x00007f5d4184556a is at code_begin+842 in > > > > > > > > [CodeBlob (0x00007f5d41845190)] > > > > > > > > Framesize: 0 > > > > > > > > BufferBlob (0x00007f5d41845190) used for panama_upcall_stub > > > > > > > > RCX=0x000000000000000a is an unknown value > > > > > > > > RDX=0x0 is NULL > > > > > > > > RSP=0x00007f5d5f69c8b0 is pointing into the stack for thread: > > > > > > > > 0x00007f5d580268c0 > > > > > > > > RBP=0x00007f5d5f69c8c0 is pointing into the stack for thread: > > > > > > > > 0x00007f5d580268c0 > > > > > > > > RSI=0x0000000000000071 is an unknown value > > > > > > > > RDI=0x00007f5d606f6108: in > > > > > > > > /usr/lib/jvm/jdk-17-panama/lib/server/libjvm.so at 0x00007f5d5f7f9000 > > > > > > > > R8 =0x0 is NULL > > > > > > > > R9 =0x00007f5d5f69c8a0 is pointing into the stack for thread: > > > > > > > > 0x00007f5d580268c0 > > > > > > > > R10=0x0 is NULL > > > > > > > > R11=0x0 is NULL > > > > > > > > R12=0x0000000091d82828 is an oop: java.lang.UnsatisfiedLinkError > > > > > > > > {0x0000000091d82828} - klass: 'java/lang/UnsatisfiedLinkError' > > > > > > > > R13=0x00007f5d1c42fbdc is pointing into metadata > > > > > > > > R14=0x00007f5d5f69c8c8 is pointing into the stack for thread: > > > > > > > > 0x00007f5d580268c0 > > > > > > > > R15=0x00007f5d580268c0 is a thread > > > > > > > > I verified with LDD if the lib I am linking to has dependencies > > > > > > > > problem but it seams to be ok. > > > > > > > > ldd --verbose /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 > > > > > > > > linux-vdso.so.1 (0x00007ffc37dcd000) > > > > > > > > libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007effdf322000) > > > > > > > > libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007effdf1e5000) > > > > > > > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007effdf096000) > > > > > > > > libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007effdf084000) > > > > > > > > libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 > > > > > > > > (0x00007effdf07d000) > > > > > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007effdee8b000) > > > > > > > > libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 > > > > > > > > (0x00007effdedd1000) > > > > > > > > libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007effded9d000) > > > > > > > > libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007effded73000) > > > > > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007effded6d000) > > > > > > > > /lib64/ld-linux-x86-64.so.2 (0x00007effdf608000) > > > > > > > > libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007effded58000) > > > > > > > > libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007effded50000) > > > > > > > > libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007effded48000) > > > > > > > > libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007effded2e000) > > > > > > > > Version information: > > > > > > > > /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0: > > > > > > > > libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6 > > > > > > > > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libGL.so.1: > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libX11.so.6: > > > > > > > > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > > > > > > > > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.26) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libm.so.6: > > > > > > > > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libXi.so.6: > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libXxf86vm.so.1: > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libc.so.6: > > > > > > > > ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 > > > > > > > > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > > > > > > > /lib/x86_64-linux-gnu/libGLdispatch.so.0: > > > > > > > > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libGLX.so.0: > > > > > > > > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libxcb.so.1: > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libdl.so.2: > > > > > > > > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > > > > > > > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libXext.so.6: > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libXau.so.6: > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libXdmcp.so.6: > > > > > > > > libbsd.so.0 (LIBBSD_0.2) => /lib/x86_64-linux-gnu/libbsd.so.0 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > /lib/x86_64-linux-gnu/libbsd.so.0: > > > > > > > > libc.so.6 (GLIBC_2.25) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.16) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.8) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 From maurizio.cimadamore at oracle.com Mon Nov 22 12:23:25 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 22 Nov 2021 12:23:25 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: References: <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> <-QTuGDa0nmGTEPQ9e09MZxEU9ozr5M4FRwmJvR330RmH9yJsaRFWk0Iat-WWquO9MFmpmJst0bsK-JTJfjM2cDsdbVl4z9QjcRKqkUftG6U=@protonmail.com> <5be0b498-8606-0ed9-0b7a-b07056098f0a@oracle.com> Message-ID: <7ba17086-1135-23fb-f030-679ba5dd89ec@oracle.com> I see what you mean. Unfortunately, having too strict of a behavior at runtime (e.g. fail early when a non-existing function is detected) might also be overly strict. There are many cases where the library is 99% there, except for one or two problematic functions (which might be delivered as macros on some platforms, but not in others). If these functions are never called, failing eagerly might seem overly harsh. Possible options are to use some kind of SPI to allow clients to override function lookup - but honestly, it seems a very complex solution. E.g. in your case you can probably tweak RuntimeHelper sources to fail early if a native symbol is not found. Maurizio On 22/11/2021 12:08, Martin Pernollet wrote: > Hi Maurizio, > > Maybe this would be more handy to run this from the program using the binding : providing the libs to JExtract has the drawback to tidying the generated library to the developer lib path. In the future I woule like not use the -l option to prevent JExtract from generating the System.load and System.loadLibrary, and write this lib loading code on the user side. > > Example use case that I got working : I generated bindings from a Mac 11.4 computer which has the lib at a given path /a/b/c. I ran from a Mac 10.15 and noticed it works perfectly by just modifying the path to the GL libs at /d/e/f. > > If I was wrong entering /d/e/g at runtime, I would like to detect unmapped functions. > > Cheers > > > Sent with ProtonMail Secure Email. > > ??????? Original Message ??????? > > Le lundi 22 novembre 2021 ? 11:41, Maurizio Cimadamore a ?crit : > >> Hi Martin, >> >> we used to have a check similar to the one you describe in an earlier >> >> version of jextract (e.g. when `-l` was specified, we would check that >> >> functions/global vars were emitted in said libs). We can probably re-add >> >> such a check. >> >> Maurizio >> >> On 21/11/2021 17:39, Martin Pernollet wrote: >> >>> Hi, >>> >>> The UnsatisfiedLinkError was triggered while invoking a method relying on a null method handle. >>> >>> When invoking jextract, I provided an include dir with multiple header files (usr/include/GL) but an incomplete list of libraries. The code is generated correctly and the user of this generated code don't see any problem at compile time. However, when running the program, glut_h will only map a subset of the generated method handles to the native libs. >>> >>> It would be convenient to get warnings about it when the program starts. Would you recommend a way to iterate over all generated method handles to check those that are null? >>> >>> /usr/lib/jvm/jdk-17-panama/bin/jextract -d ./src/main/java/ --source -t opengl.ubuntu.v20 \ >>> >>> -lGL \ >>> >>> -l/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 \ >>> >>> -l/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1 \ << that one was missing >>> >>> -I /usr/include/GL \ >>> >>> -C-F/usr/include/GL \ >>> >>> /usr/include/GL/glut.h >>> >>> public class glut_h extends glut_h_6 { >>> >>> static { >>> System.loadLibrary("GL"); >>> System.load("/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0"); >>> System.load("/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1"); // fixing jextract lib list let glut_h map the metod handle to the native libs >>> } >>> >>> >>> Cheers, >>> >>> Martin >>> >>> ??????? Original Message ??????? >>> >>> Le lundi 15 novembre 2021 ? 11:43, Maurizio Cimadamore maurizio.cimadamore at oracle.com a ?crit : >>> >>>> Hi, >>>> >>>> from the top of my head, this looks like an exception thrown while you >>>> >>>> are executing an upcall. And it also looks like you are missing some of >>>> >>>> the latest patches which will generate a "normal" stack trace. So you >>>> >>>> only see the exception name (UnsatisfiedLink). >>>> >>>> As a general rule, if an exception occurs when an upcall is executing, >>>> >>>> only option is to exit the Java program, so that we don't leave the >>>> >>>> native code in a potentially bad state. >>>> >>>> But more recent releases of the linker API do a better job at presenting >>>> >>>> this as an "exception" (although one that cannot be caught) rather than >>>> >>>> a blunt crash. >>>> >>>> If you can't update to a newer build, I'd look into all upcall code, >>>> >>>> looking for all pieces of code which might do System.load/loadLibrary. >>>> >>>> Maurizio >>>> >>>> On 15/11/2021 07:33, Martin Pernollet wrote: >>>> >>>>> Hi, >>>>> >>>>> I am now on Ubuntu. The original teapot sample is working (just >>>>> >>>>> required to change glutDisplayFunc$func to glutDisplayFunc$callback). >>>>> >>>>> I got an UnstasfiedLinkException with other programs. I wonder if you >>>>> >>>>> have a suggestion to help me understand my mistake? LDD command does >>>>> >>>>> not help. Like for the NPE, we lack a bit of info for debugging. >>>>> >>>>> Console says >>>>> >>>>> Uncaught exception: >>>>> >>>>> java.lang.UnsatisfiedLinkError >>>>> >>>>> {0x0000000091ac9b58} - klass: 'java/lang/UnsatisfiedLinkError' >>>>> >>>>> A fatal error has been detected by the Java Runtime Environment: >>>>> ================================================================ >>>>> >>>>> #? Internal Error (universalUpcallHandler.cpp:113), pid=33668, tid=33677 >>>>> >>>>> #? Error: ShouldNotReachHere() >>>>> >>>>> Core dump says (see attached the complete core dump file) >>>>> >>>>> Current thread (0x00007f5d580268c0):? JavaThread "main" >>>>> >>>>> [_thread_in_Java, id=35593, stack(0x00007f5d5f59e000,0x00007f5d5f69f000)] >>>>> >>>>> Stack: [0x00007f5d5f59e000,0x00007f5d5f69f000], >>>>> >>>>> sp=0x00007f5d5f69c8b0,? free space=1018k >>>>> >>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>> >>>>> C=native code) >>>>> >>>>> V? [libjvm.so+0xd993a3] >>>>> >>>>> ProgrammableUpcallHandler::handle_uncaught_exception(oopDesc*)+0x43 >>>>> >>>>> v? ~BufferBlob::panama_upcall_stub >>>>> >>>>> C? [libglut.so.3.9.0+0x20895]? glutMainLoopEvent+0x2a5 >>>>> >>>>> Register to memory mapping: >>>>> >>>>> RAX=0x00007f5d60cc4000 points into unknown readable memory: >>>>> >>>>> 0x0000000000000058 | 58 00 00 00 00 00 00 00 >>>>> >>>>> RBX=0x00007f5d4184556a is at code_begin+842 in >>>>> >>>>> [CodeBlob (0x00007f5d41845190)] >>>>> >>>>> Framesize: 0 >>>>> >>>>> BufferBlob (0x00007f5d41845190) used for panama_upcall_stub >>>>> >>>>> RCX=0x000000000000000a is an unknown value >>>>> >>>>> RDX=0x0 is NULL >>>>> >>>>> RSP=0x00007f5d5f69c8b0 is pointing into the stack for thread: >>>>> >>>>> 0x00007f5d580268c0 >>>>> >>>>> RBP=0x00007f5d5f69c8c0 is pointing into the stack for thread: >>>>> >>>>> 0x00007f5d580268c0 >>>>> >>>>> RSI=0x0000000000000071 is an unknown value >>>>> >>>>> RDI=0x00007f5d606f6108: in >>>>> >>>>> /usr/lib/jvm/jdk-17-panama/lib/server/libjvm.so at 0x00007f5d5f7f9000 >>>>> >>>>> R8 =0x0 is NULL >>>>> >>>>> R9 =0x00007f5d5f69c8a0 is pointing into the stack for thread: >>>>> >>>>> 0x00007f5d580268c0 >>>>> >>>>> R10=0x0 is NULL >>>>> >>>>> R11=0x0 is NULL >>>>> >>>>> R12=0x0000000091d82828 is an oop: java.lang.UnsatisfiedLinkError >>>>> >>>>> {0x0000000091d82828} - klass: 'java/lang/UnsatisfiedLinkError' >>>>> >>>>> R13=0x00007f5d1c42fbdc is pointing into metadata >>>>> >>>>> R14=0x00007f5d5f69c8c8 is pointing into the stack for thread: >>>>> >>>>> 0x00007f5d580268c0 >>>>> >>>>> R15=0x00007f5d580268c0 is a thread >>>>> >>>>> I verified with LDD if the lib I am linking to has dependencies >>>>> >>>>> problem but it seams to be ok. >>>>> >>>>> ldd --verbose /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 >>>>> >>>>> linux-vdso.so.1 (0x00007ffc37dcd000) >>>>> >>>>> libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007effdf322000) >>>>> >>>>> libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007effdf1e5000) >>>>> >>>>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007effdf096000) >>>>> >>>>> libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007effdf084000) >>>>> >>>>> libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 >>>>> >>>>> (0x00007effdf07d000) >>>>> >>>>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007effdee8b000) >>>>> >>>>> libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 >>>>> >>>>> (0x00007effdedd1000) >>>>> >>>>> libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007effded9d000) >>>>> >>>>> libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007effded73000) >>>>> >>>>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007effded6d000) >>>>> >>>>> /lib64/ld-linux-x86-64.so.2 (0x00007effdf608000) >>>>> >>>>> libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007effded58000) >>>>> >>>>> libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007effded50000) >>>>> >>>>> libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007effded48000) >>>>> >>>>> libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007effded2e000) >>>>> >>>>> Version information: >>>>> >>>>> /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0: >>>>> >>>>> libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libGL.so.1: >>>>> >>>>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libX11.so.6: >>>>> >>>>> libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 >>>>> >>>>> libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.26) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libm.so.6: >>>>> >>>>> ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libXi.so.6: >>>>> >>>>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libXxf86vm.so.1: >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libc.so.6: >>>>> >>>>> ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 >>>>> >>>>> ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 >>>>> >>>>> /lib/x86_64-linux-gnu/libGLdispatch.so.0: >>>>> >>>>> libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 >>>>> >>>>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libGLX.so.0: >>>>> >>>>> libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 >>>>> >>>>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libxcb.so.1: >>>>> >>>>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libdl.so.2: >>>>> >>>>> ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 >>>>> >>>>> libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libXext.so.6: >>>>> >>>>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libXau.so.6: >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libXdmcp.so.6: >>>>> >>>>> libbsd.so.0 (LIBBSD_0.2) => /lib/x86_64-linux-gnu/libbsd.so.0 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> /lib/x86_64-linux-gnu/libbsd.so.0: >>>>> >>>>> libc.so.6 (GLIBC_2.25) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.16) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.8) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 >>>>> >>>>> libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 From themode at outlook.fr Sun Nov 21 19:21:11 2021 From: themode at outlook.fr (Felix Cravic) Date: Sun, 21 Nov 2021 19:21:11 +0000 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: If it needs to be implemented through JNI, you may be right. However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code. Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms. ?You will be able to declare the native methods in Java, but the native library will need to be compiled for multiple platforms (and architecture) I don't understand why you should emphasize this. Does this bring any additional problems? ?JNI comes with overhead. Correct me if I am wrong, but I believe JIT compilers to work using an important number of stubs to allow de-optimization which would not work well with the said overhead (the alternative would be to move the work into the native code, but it doesn't really serve the original goal of being java-only) This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related. So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only". Cannot disagree here. Though Java would currently not be suited for a project benefiting from such feature, which is a shame considering how little API change it requires (feel free to correct me). The closest alternative we have today is dynamic class loading, which is really good for most use-case but not all. ________________________________ De : Glavo Envoy? : dimanche 21 novembre 2021 20:04 ? : Felix Cravic Cc : panama-dev at openjdk.java.net Objet : Re: Support for allocation of executable memory Sorry, in the last sentence of that email, I wanted to say "just" instead of "only". I am using Google translate to write email. Please forgive me for my problems in grammar and words. Glavo > ?2021?11?22??? ??3:00??? which would involve maintaining a native dependency and building it for every potential platform If it needs to be implemented through JNI, you may be right. However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code. Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms. not to mention the fact that every execution will have to pass through JNI/Linker API I don't understand why you should emphasize this. Does this bring any additional problems? I however disagree with the "just" This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related. So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only". Felix Cravic > ?2021?11?22??? ??2:41??? I agree that there are reasons why it could not have its place in Panama, like OS limitations complicating the API design & it being another pretty unsafe feature. I however disagree with the "just", which would involve maintaining a native dependency and building it for every potential platform, not to mention the fact that every execution will have to pass through JNI/Linker API. By that point I doubt that Java would be the right tool for the job, or is it perhaps what you meant? ________________________________ De : Glavo > Envoy? : dimanche 21 novembre 2021 19:19 ? : Felix Cravic > Cc : panama-dev at openjdk.java.net > Objet : Re: Support for allocation of executable memory I don't think Panama should provide special support for it. To do this, you just need to create the binding of the relevant system API (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) with the foreign linker API and call it. Felix Cravic > ?2021?11?22??? ??1:01??? Hello, I was wondering if there has ever been any discussion about supporting allocation of executable memory (and then its execution). The use cases I have in mind are emulation, very hot paths requiring specialized assembly (which could still fallback to jvm bytecode if unavailable), and a potential option to keep the whole application written in a JVM language. I doubt that such addition would drastically change the API, perhaps some concern about OS specific restrictions (e.g. write-xor-execute memory protection), and platform not supporting JIT compilation at all (IOS, potentially problematic for Graal & project Leyden) Discussion would be appreciated! From themode at outlook.fr Sun Nov 21 19:58:33 2021 From: themode at outlook.fr (Felix Cravic) Date: Sun, 21 Nov 2021 19:58:33 +0000 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: Do you have any benchmark comparing JNI to the linker API? Last time I checked those were similar and the JEP mentions "similar performance". I am aware of how the API works, I am however still not convinced that it fixes my previous points. Sure you can implement the Java side solely in Java, but you will obviously still need to compile the native library for multiple platforms & architectures. ________________________________ De : Glavo Envoy? : dimanche 21 novembre 2021 20:51 ? : Felix Cravic Cc : panama-dev at openjdk.java.net Objet : Re: Support for allocation of executable memory You're talking about the way JNI works, not the way Panama Foreign Linker API works. All the problems you mentioned do not apply to Panama. The Foreign Linker API does not require you to write any native code, let alone compile native code. You only need to write pure Java code to implement it. Reducing the cost of native calls is also one of Panama's goals. I believe that the cost of calling native wrappers implemented through the Foreign Linker API is low enough in common Java running environments. Forgive me for not being familiar with these system APIs, so I can't provide you with an example implementation of this function here. I just copy an example given by the official here. I believe it can make you understand how the Foreign Linker API works: // 1. Find foreign function on the C library path MethodHandle radixSort = CLinker.getInstance().downcallHandle( CLinker.systemLookup().lookup("radixsort"), ...); // 2. Allocate on-heap memory to store four strings String[] javaStrings = { "mouse", "cat", "dog", "car" }; // 3. Allocate off-heap memory to store four pointers MemorySegment offHeap = MemorySegment.allocateNative( MemoryLayout.ofSequence(javaStrings.length, CLinker.C_POINTER), ...); // 4. Copy the strings from on-heap to off-heap for (int i = 0; i < javaStrings.length; i++) { // Allocate a string off-heap, then store a pointer to it MemorySegment cString = CLinker.toCString(javaStrings[i], newImplicitScope()); MemoryAccess.setAddressAtIndex(offHeap, i, cString.address()); } // 5. Sort the off-heap data by calling the foreign function radixSort.invoke(offHeap.address(), javaStrings.length, MemoryAddress.NULL, '\0'); // 6. Copy the (reordered) strings from off-heap to on-heap for (int i = 0; i < javaStrings.length; i++) { MemoryAddress cStringPtr = MemoryAccess.getAddressAtIndex(offHeap, i); javaStrings[i] = CLinker.toJavaStringRestricted(cStringPtr); } assert Arrays.equals(javaStrings, new String[] {"car", "cat", "dog", "mouse"}); // true It is recommended that you read JEP 419 in its entirety first to understand Panama, or take a look at the description of Panama FFI in this document: https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md Felix Cravic > ?2021?11?22??? ??3:21??? If it needs to be implemented through JNI, you may be right. However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code. Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms. You will be able to declare the native methods in Java, but the native library will need to be compiled for multiple platforms (and architecture) I don't understand why you should emphasize this. Does this bring any additional problems? JNI comes with overhead. Correct me if I am wrong, but I believe JIT compilers to work using an important number of stubs to allow de-optimization which would not work well with the said overhead (the alternative would be to move the work into the native code, but it doesn't really serve the original goal of being java-only) This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related. So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only". Cannot disagree here. Though Java would currently not be suited for a project benefiting from such feature, which is a shame considering how little API change it requires (feel free to correct me). The closest alternative we have today is dynamic class loading, which is really good for most use-case but not all. ________________________________ De : Glavo > Envoy? : dimanche 21 novembre 2021 20:04 ? : Felix Cravic > Cc : panama-dev at openjdk.java.net > Objet : Re: Support for allocation of executable memory Sorry, in the last sentence of that email, I wanted to say "just" instead of "only". I am using Google translate to write email. Please forgive me for my problems in grammar and words. Glavo > ?2021?11?22??? ??3:00??? which would involve maintaining a native dependency and building it for every potential platform If it needs to be implemented through JNI, you may be right. However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code. Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms. not to mention the fact that every execution will have to pass through JNI/Linker API I don't understand why you should emphasize this. Does this bring any additional problems? I however disagree with the "just" This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related. So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only". Felix Cravic > ?2021?11?22??? ??2:41??? I agree that there are reasons why it could not have its place in Panama, like OS limitations complicating the API design & it being another pretty unsafe feature. I however disagree with the "just", which would involve maintaining a native dependency and building it for every potential platform, not to mention the fact that every execution will have to pass through JNI/Linker API. By that point I doubt that Java would be the right tool for the job, or is it perhaps what you meant? ________________________________ De : Glavo > Envoy? : dimanche 21 novembre 2021 19:19 ? : Felix Cravic > Cc : panama-dev at openjdk.java.net > Objet : Re: Support for allocation of executable memory I don't think Panama should provide special support for it. To do this, you just need to create the binding of the relevant system API (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) with the foreign linker API and call it. Felix Cravic > ?2021?11?22??? ??1:01??? Hello, I was wondering if there has ever been any discussion about supporting allocation of executable memory (and then its execution). The use cases I have in mind are emulation, very hot paths requiring specialized assembly (which could still fallback to jvm bytecode if unavailable), and a potential option to keep the whole application written in a JVM language. I doubt that such addition would drastically change the API, perhaps some concern about OS specific restrictions (e.g. write-xor-execute memory protection), and platform not supporting JIT compilation at all (IOS, potentially problematic for Graal & project Leyden) Discussion would be appreciated! From themode at outlook.fr Sun Nov 21 20:36:21 2021 From: themode at outlook.fr (Felix Cravic) Date: Sun, 21 Nov 2021 20:36:21 +0000 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: I emphasize here again that Panama is different from JNI, There is no need to compile the native library. All we need is: 1. Through SymbolLookup::lookup, find the symbols of system API in the system library; 2. Through CLinker::downcallHandle, generate MethodHandle corresponding to the system API; 3. Call it. This is completely implemented in Java code, and there is no need to use native code, let alone compile native code. ?Indeed I guess that it works for the allocation phase, how would you run the code given an executable memory address? ________________________________ De : Glavo Envoy? : dimanche 21 novembre 2021 21:30 ? : Felix Cravic Cc : panama-dev at openjdk.java.net Objet : Re: Support for allocation of executable memory Do you have any benchmark comparing JNI to the linker API? Last time I checked those were similar and the JEP mentions "similar performance". I am aware of how the API works, I am however still not convinced that it fixes my previous points. At this stage, the performance of Panama will not be higher than that of JNI, because its back end is still based on JNI, so it should have similar performance. At present, Panama is still some distance away from maturity, but it leaves more room for optimization for the JVM. Please wait patiently for it to focus on optimizing performance after it matures in function. Sure you can implement the Java side solely in Java, but you will obviously still need to compile the native library for multiple platforms & architectures. I emphasize here again that Panama is different from JNI, There is no need to compile the native library. All we need is: 1. Through SymbolLookup::lookup, find the symbols of system API in the system library; 2. Through CLinker::downcallHandle, generate MethodHandle corresponding to the system API; 3. Call it. This is completely implemented in Java code, and there is no need to use native code, let alone compile native code. Felix Cravic > ?2021?11?22??? ??3:58??? Do you have any benchmark comparing JNI to the linker API? Last time I checked those were similar and the JEP mentions "similar performance". I am aware of how the API works, I am however still not convinced that it fixes my previous points. Sure you can implement the Java side solely in Java, but you will obviously still need to compile the native library for multiple platforms & architectures. ________________________________ De : Glavo > Envoy? : dimanche 21 novembre 2021 20:51 ? : Felix Cravic > Cc : panama-dev at openjdk.java.net > Objet : Re: Support for allocation of executable memory You're talking about the way JNI works, not the way Panama Foreign Linker API works. All the problems you mentioned do not apply to Panama. The Foreign Linker API does not require you to write any native code, let alone compile native code. You only need to write pure Java code to implement it. Reducing the cost of native calls is also one of Panama's goals. I believe that the cost of calling native wrappers implemented through the Foreign Linker API is low enough in common Java running environments. Forgive me for not being familiar with these system APIs, so I can't provide you with an example implementation of this function here. I just copy an example given by the official here. I believe it can make you understand how the Foreign Linker API works: // 1. Find foreign function on the C library path MethodHandle radixSort = CLinker.getInstance().downcallHandle( CLinker.systemLookup().lookup("radixsort"), ...); // 2. Allocate on-heap memory to store four strings String[] javaStrings = { "mouse", "cat", "dog", "car" }; // 3. Allocate off-heap memory to store four pointers MemorySegment offHeap = MemorySegment.allocateNative( MemoryLayout.ofSequence(javaStrings.length, CLinker.C_POINTER), ...); // 4. Copy the strings from on-heap to off-heap for (int i = 0; i < javaStrings.length; i++) { // Allocate a string off-heap, then store a pointer to it MemorySegment cString = CLinker.toCString(javaStrings[i], newImplicitScope()); MemoryAccess.setAddressAtIndex(offHeap, i, cString.address()); } // 5. Sort the off-heap data by calling the foreign function radixSort.invoke(offHeap.address(), javaStrings.length, MemoryAddress.NULL, '\0'); // 6. Copy the (reordered) strings from off-heap to on-heap for (int i = 0; i < javaStrings.length; i++) { MemoryAddress cStringPtr = MemoryAccess.getAddressAtIndex(offHeap, i); javaStrings[i] = CLinker.toJavaStringRestricted(cStringPtr); } assert Arrays.equals(javaStrings, new String[] {"car", "cat", "dog", "mouse"}); // true It is recommended that you read JEP 419 in its entirety first to understand Panama, or take a look at the description of Panama FFI in this document: https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md Felix Cravic > ?2021?11?22??? ??3:21??? If it needs to be implemented through JNI, you may be right. However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code. Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms. You will be able to declare the native methods in Java, but the native library will need to be compiled for multiple platforms (and architecture) I don't understand why you should emphasize this. Does this bring any additional problems? JNI comes with overhead. Correct me if I am wrong, but I believe JIT compilers to work using an important number of stubs to allow de-optimization which would not work well with the said overhead (the alternative would be to move the work into the native code, but it doesn't really serve the original goal of being java-only) This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related. So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only". Cannot disagree here. Though Java would currently not be suited for a project benefiting from such feature, which is a shame considering how little API change it requires (feel free to correct me). The closest alternative we have today is dynamic class loading, which is really good for most use-case but not all. ________________________________ De : Glavo > Envoy? : dimanche 21 novembre 2021 20:04 ? : Felix Cravic > Cc : panama-dev at openjdk.java.net > Objet : Re: Support for allocation of executable memory Sorry, in the last sentence of that email, I wanted to say "just" instead of "only". I am using Google translate to write email. Please forgive me for my problems in grammar and words. Glavo > ?2021?11?22??? ??3:00??? which would involve maintaining a native dependency and building it for every potential platform If it needs to be implemented through JNI, you may be right. However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code. Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms. not to mention the fact that every execution will have to pass through JNI/Linker API I don't understand why you should emphasize this. Does this bring any additional problems? I however disagree with the "just" This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related. So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only". Felix Cravic > ?2021?11?22??? ??2:41??? I agree that there are reasons why it could not have its place in Panama, like OS limitations complicating the API design & it being another pretty unsafe feature. I however disagree with the "just", which would involve maintaining a native dependency and building it for every potential platform, not to mention the fact that every execution will have to pass through JNI/Linker API. By that point I doubt that Java would be the right tool for the job, or is it perhaps what you meant? ________________________________ De : Glavo > Envoy? : dimanche 21 novembre 2021 19:19 ? : Felix Cravic > Cc : panama-dev at openjdk.java.net > Objet : Re: Support for allocation of executable memory I don't think Panama should provide special support for it. To do this, you just need to create the binding of the relevant system API (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) with the foreign linker API and call it. Felix Cravic > ?2021?11?22??? ??1:01??? Hello, I was wondering if there has ever been any discussion about supporting allocation of executable memory (and then its execution). The use cases I have in mind are emulation, very hot paths requiring specialized assembly (which could still fallback to jvm bytecode if unavailable), and a potential option to keep the whole application written in a JVM language. I doubt that such addition would drastically change the API, perhaps some concern about OS specific restrictions (e.g. write-xor-execute memory protection), and platform not supporting JIT compilation at all (IOS, potentially problematic for Graal & project Leyden) Discussion would be appreciated! From maurizio.cimadamore at oracle.com Mon Nov 22 15:40:39 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 22 Nov 2021 15:40:39 +0000 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: On 22/11/2021 10:59, Maurizio Cimadamore wrote: > Also, for some mysterious reasons I can't see some parts of the discussion These emails were stuck in moderator queue - they are unstuck now. Maurizio From sviswanathan at openjdk.java.net Mon Nov 22 16:18:48 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Mon, 22 Nov 2021 16:18:48 GMT Subject: [vectorIntrinsics] Integrated: Merge panama-vector:vectorIntrinsics+compress In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:13:23 GMT, Sandhya Viswanathan wrote: > Merge vectorIntrinsics+compress into vectorIntrinsics. > @nsjian need your help to update test/hotspot/gtest/aarch64/asmtest.out.h. > > Best Regards, > Sandhya This pull request has now been integrated. Changeset: e16d2f53 Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/panama-vector/commit/e16d2f5341f631b9e782ea84af09219d637d5b60 Stats: 7218 lines in 140 files changed: 7139 ins; 19 del; 60 mod Merge panama-vector:vectorIntrinsics+compress Reviewed-by: jbhateja ------------- PR: https://git.openjdk.java.net/panama-vector/pull/167 From mail at smogura.eu Mon Nov 22 16:23:19 2021 From: mail at smogura.eu (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=) Date: Mon, 22 Nov 2021 16:23:19 +0000 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: Hi, Once I created this project https://github.com/rsmogura/panama-io (just to check a few things) - that's not an official thing, and right now I don't have a lot of time to work more on it. I don't remember exact numbers, but I think I could go up to 10% better performance for reads than the original Socket API. (It was created as drop-in replacement for socket API). Having operations completely in Native memory could make this number even better, but it's as well a big change from down to top (we would have to work on native buffered than byte[] streams...). Kind regards, Rado ________________________________ From: panama-dev on behalf of Felix Cravic Sent: Sunday, November 21, 2021 20:58 To: Glavo Cc: panama-dev at openjdk.java.net Subject: RE: Support for allocation of executable memory Do you have any benchmark comparing JNI to the linker API? Last time I checked those were similar and the JEP mentions "similar performance". I am aware of how the API works, I am however still not convinced that it fixes my previous points. Sure you can implement the Java side solely in Java, but you will obviously still need to compile the native library for multiple platforms & architectures. ________________________________ De : Glavo Envoy? : dimanche 21 novembre 2021 20:51 ? : Felix Cravic Cc : panama-dev at openjdk.java.net Objet : Re: Support for allocation of executable memory You're talking about the way JNI works, not the way Panama Foreign Linker API works. All the problems you mentioned do not apply to Panama. The Foreign Linker API does not require you to write any native code, let alone compile native code. You only need to write pure Java code to implement it. Reducing the cost of native calls is also one of Panama's goals. I believe that the cost of calling native wrappers implemented through the Foreign Linker API is low enough in common Java running environments. Forgive me for not being familiar with these system APIs, so I can't provide you with an example implementation of this function here. I just copy an example given by the official here. I believe it can make you understand how the Foreign Linker API works: // 1. Find foreign function on the C library path MethodHandle radixSort = CLinker.getInstance().downcallHandle( CLinker.systemLookup().lookup("radixsort"), ...); // 2. Allocate on-heap memory to store four strings String[] javaStrings = { "mouse", "cat", "dog", "car" }; // 3. Allocate off-heap memory to store four pointers MemorySegment offHeap = MemorySegment.allocateNative( MemoryLayout.ofSequence(javaStrings.length, CLinker.C_POINTER), ...); // 4. Copy the strings from on-heap to off-heap for (int i = 0; i < javaStrings.length; i++) { // Allocate a string off-heap, then store a pointer to it MemorySegment cString = CLinker.toCString(javaStrings[i], newImplicitScope()); MemoryAccess.setAddressAtIndex(offHeap, i, cString.address()); } // 5. Sort the off-heap data by calling the foreign function radixSort.invoke(offHeap.address(), javaStrings.length, MemoryAddress.NULL, '\0'); // 6. Copy the (reordered) strings from off-heap to on-heap for (int i = 0; i < javaStrings.length; i++) { MemoryAddress cStringPtr = MemoryAccess.getAddressAtIndex(offHeap, i); javaStrings[i] = CLinker.toJavaStringRestricted(cStringPtr); } assert Arrays.equals(javaStrings, new String[] {"car", "cat", "dog", "mouse"}); // true It is recommended that you read JEP 419 in its entirety first to understand Panama, or take a look at the description of Panama FFI in this document: https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md Felix Cravic > ?2021?11?22??? ??3:21??? If it needs to be implemented through JNI, you may be right. However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code. Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms. You will be able to declare the native methods in Java, but the native library will need to be compiled for multiple platforms (and architecture) I don't understand why you should emphasize this. Does this bring any additional problems? JNI comes with overhead. Correct me if I am wrong, but I believe JIT compilers to work using an important number of stubs to allow de-optimization which would not work well with the said overhead (the alternative would be to move the work into the native code, but it doesn't really serve the original goal of being java-only) This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related. So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only". Cannot disagree here. Though Java would currently not be suited for a project benefiting from such feature, which is a shame considering how little API change it requires (feel free to correct me). The closest alternative we have today is dynamic class loading, which is really good for most use-case but not all. ________________________________ De : Glavo > Envoy? : dimanche 21 novembre 2021 20:04 ? : Felix Cravic > Cc : panama-dev at openjdk.java.net > Objet : Re: Support for allocation of executable memory Sorry, in the last sentence of that email, I wanted to say "just" instead of "only". I am using Google translate to write email. Please forgive me for my problems in grammar and words. Glavo > ?2021?11?22??? ??3:00??? which would involve maintaining a native dependency and building it for every potential platform If it needs to be implemented through JNI, you may be right. However, for Panama, although we still need to use different codes for different operating systems, all this can be implemented through pure java code. Additional dependencies are unnecessary because these functions should be part of the operating system. Because it only needs to be implemented in Java code, it is not necessary to compile on multiple platforms. not to mention the fact that every execution will have to pass through JNI/Linker API I don't understand why you should emphasize this. Does this bring any additional problems? I however disagree with the "just" This implementation does improve the difficulty of user code maintenance, but this function itself is low-level, unsafe and platform related, and the code using it is often platform related. So I believe that when it is really needed, the problems caused by this part are relatively insignificant, so I use the word "only". Felix Cravic > ?2021?11?22??? ??2:41??? I agree that there are reasons why it could not have its place in Panama, like OS limitations complicating the API design & it being another pretty unsafe feature. I however disagree with the "just", which would involve maintaining a native dependency and building it for every potential platform, not to mention the fact that every execution will have to pass through JNI/Linker API. By that point I doubt that Java would be the right tool for the job, or is it perhaps what you meant? ________________________________ De : Glavo > Envoy? : dimanche 21 novembre 2021 19:19 ? : Felix Cravic > Cc : panama-dev at openjdk.java.net > Objet : Re: Support for allocation of executable memory I don't think Panama should provide special support for it. To do this, you just need to create the binding of the relevant system API (e.g. `VirtualAlloc` and `VirtualProtect` on Windows, or `mmap` on Linux) with the foreign linker API and call it. Felix Cravic > ?2021?11?22??? ??1:01??? Hello, I was wondering if there has ever been any discussion about supporting allocation of executable memory (and then its execution). The use cases I have in mind are emulation, very hot paths requiring specialized assembly (which could still fallback to jvm bytecode if unavailable), and a potential option to keep the whole application written in a JVM language. I doubt that such addition would drastically change the API, perhaps some concern about OS specific restrictions (e.g. write-xor-execute memory protection), and platform not supporting JIT compilation at all (IOS, potentially problematic for Graal & project Leyden) Discussion would be appreciated! From paul.sandoz at oracle.com Mon Nov 22 16:41:15 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 22 Nov 2021 16:41:15 +0000 Subject: Support for allocation of executable memory In-Reply-To: References: Message-ID: <9935FEF7-0779-4863-A8A8-92618F4ADF47@oracle.com> Hi, Replying at the top of the thread. This reminds me of the early days experimenting with native code snippets and binding them to method handles. We prototyped that for use with vectorization. See http://cr.openjdk.java.net/~psandoz/conferences/2015-JavaOne/j1-2015-unsafe-CON7076.pdf That was in 2015! It's very encouraging to reflect back on that and see the progress with Project Panama. As shown in the thread it's possible with Panama?s FFM API to do something similar, but the degree of optimization compared to C2 intrinsics will be limited right now. The code snippets prototype was more optimally integrated with C2, more intrinsic-like than native-like. Perhaps over time it may be possible to close the gap for certain kinds of native functionality (i.e. like that internal JNI fast path the name of which escapes me right now), which depends on the properties of that functionality. Paul. > On Nov 20, 2021, at 11:33 PM, Felix Cravic wrote: > > Hello, I was wondering if there has ever been any discussion about supporting allocation of executable memory (and then its execution). The use cases I have in mind are emulation, very hot paths requiring specialized assembly (which could still fallback to jvm bytecode if unavailable), and a potential option to keep the whole application written in a JVM language. > > I doubt that such addition would drastically change the API, perhaps some concern about OS specific restrictions (e.g. write-xor-execute memory protection), and platform not supporting JIT compilation at all (IOS, potentially problematic for Graal & project Leyden) > > Discussion would be appreciated! From robbepincket at live.be Mon Nov 22 17:03:01 2021 From: robbepincket at live.be (Robbe Pincket) Date: Mon, 22 Nov 2021 17:03:01 +0000 Subject: How to validate the successfulness of the c2 compiler in generating vectorized assembly Message-ID: Hi Recently, A coworker converted part of our codebase to use the new incubating vector api. And although a noticable increase in performance was measured, the allocation rate under even mild stress of the system has skyrocketed to 1.3 gb/s, due to the need of creating temporary arrays. After a partial rewrite, to avoid most of those allocations or replace a few double arrays to short or byte arrays, I was expecting this rate to significantly drop. This did not seem to happen. Instead there are many more array allocations happening in the creation of the vectors and vector masks themselves. On top of that, the code seems to now be noticable slower than the original code. It seems that the c2 compiler is failing to generate any vectorized code. So here is my question: What is the best way to validate whether the c2 compiler is actually using vectorized opcodes, and if not, get feedback from the compiler on why it fails to do so. Thanks in advance Robbe Pincket From maurizio.cimadamore at oracle.com Mon Nov 22 17:06:10 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 22 Nov 2021 17:06:10 +0000 Subject: Support for allocation of executable memory In-Reply-To: <9935FEF7-0779-4863-A8A8-92618F4ADF47@oracle.com> References: <9935FEF7-0779-4863-A8A8-92618F4ADF47@oracle.com> Message-ID: <85187680-9f03-953e-97f4-23df05afacc8@oracle.com> On 22/11/2021 16:41, Paul Sandoz wrote: > As shown in the thread it's possible with Panama?s FFM API to do something similar, but the degree of optimization compared to C2 intrinsics will be limited right now. The code snippets prototype was more optimally integrated with C2, more intrinsic-like than native-like. Perhaps over time it may be possible to close the gap for certain kinds of native functionality (i.e. like that internal JNI fast path the name of which escapes me right now), which depends on the properties of that functionality. I think it would be ultimately great to land in the place you describe. One caveat: to get there, having executable memory segments is just the tip of the iceberg. That is, of course to enable that at some point we will need to create a memory segment which points to a piece of executable memory - but that's a low-level detail. The high-order bit missing is that we need a way to describe the computation that is associated with that intrinsic. Directly acccepting assembly is too low-level - and specifying behavior in Java is too high-level. As in the case of the Vector API, it seems like something "in between" is needed. In other words, the Foreign API gives us the basic capability to create a memory segment and (through linker API, as Glavo noted) change its permission to executable. We can then even link the address of that segment into a method handle, using the linker API, and have it behave as a regular native function. But to get to C2 intrinsification nirvana, we need a way to describe what's inside the computation bubble. Maurizio From duke at openjdk.java.net Mon Nov 22 17:18:33 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Mon, 22 Nov 2021 17:18:33 GMT Subject: [vectorIntrinsics] RFR: x86 intrinsics for zero extension casts [v3] In-Reply-To: References: Message-ID: > This patch implements the zero extension intrinsics for x86. I also fix the bug with the previous implementation where the sign elimination mask is calculated incorrectly and add several tests for this operation. I hope this will be useful. > > Thank you very much. Mai ??ng Qu?n Anh 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 four additional commits since the last revision: - fix mistaken is_unsigned parameter - Merge branch 'vectorIntrinsics' into unsignedCastIntrinsics - renumber vector operations - vector unsigned cast intrinsics ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/155/files - new: https://git.openjdk.java.net/panama-vector/pull/155/files/e97e68e1..ddbb76d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=155&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=155&range=01-02 Stats: 916307 lines in 2434 files changed: 473164 ins; 434058 del; 9085 mod Patch: https://git.openjdk.java.net/panama-vector/pull/155.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/155/head:pull/155 PR: https://git.openjdk.java.net/panama-vector/pull/155 From martin.pernollet at protonmail.com Mon Nov 22 17:44:38 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Mon, 22 Nov 2021 17:44:38 +0000 Subject: [External] : Re: JEP-412 & OpenGL In-Reply-To: <7ba17086-1135-23fb-f030-679ba5dd89ec@oracle.com> References: <3VY2n11rRzKDNGFQcIwQpCIQQvIjk-sQh7F4a_rexj35tZMo5lAwqbg-orXVR5xntvqXo0ML9M8xxosGa69Ckeh2n742tmEgrElb1yvZZV8=@protonmail.com> <8FD534F2-CEF4-42DB-80E6-25C823C35067@oracle.com> <-QTuGDa0nmGTEPQ9e09MZxEU9ozr5M4FRwmJvR330RmH9yJsaRFWk0Iat-WWquO9MFmpmJst0bsK-JTJfjM2cDsdbVl4z9QjcRKqkUftG6U=@protonmail.com> <5be0b498-8606-0ed9-0b7a-b07056098f0a@oracle.com> <7ba17086-1135-23fb-f030-679ba5dd89ec@oracle.com> Message-ID: I agree : failing, warning, or doing nothing should be the decision of the client. I was rather asking how to get the list of all MethodHandle in a package to check if they are null in order to print their name. I have been able to write this using a bit of introspection. Output is ---------------------------------------------------------------- Following native functions have link status : MISSING ---------------------------------------------------------------- gluBuild1DMipmaps: (constants$931.gluBuild1DMipmaps$MH) link is MISSING gluBuild2DMipmapLevels: (constants$931.gluBuild2DMipmapLevels$MH) link is MISSING gluBuild2DMipmaps: (constants$931.gluBuild2DMipmaps$MH) link is MISSING ... Program is import jdk.incubator.foreign.MemoryAddress; import jdk.incubator.foreign.SymbolLookup; import opengl.ubuntu.v20.RuntimeHelper; import java.io.File; import java.io.IOException; import java.lang.invoke.MethodHandle; import java.lang.reflect.Field; import java.net.URL; import java.util.ArrayList; import java.util.Enumeration; import java.util.List; import java.util.Optional; import java.util.regex.Pattern; /** * Run me with VM args * * * --enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.foreign -Djava.library.path=.:/usr/lib/x86_64-linux-gnu/ * * * To build this program, you need to change RuntimeHelper to public as well as its lookup method. If you can't, just set it to null * * To verify that this program works properly, you need to make an explicit load of libraries and ensure that generated code * does not do it, as loading class names from the class path will trigger loading. E.g. do this : * * * public class glut_h extends glut_h_6 { * * static { * //System.loadLibrary("GL"); * //System.load("/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0"); * //System.load("/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1"); * } * * * And then manually load the libraries in the below check program */ public class CheckLookup { public static void main(String[] args) throws IOException, ClassNotFoundException, IllegalAccessException { System.loadLibrary("GL"); System.load("/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0"); //System.load("/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1"); // Let's forget this /** If you can not modify RuntimeHelper.lookup() visibility, toggle to false */ SymbolLookup lookup = null;//RuntimeHelper.lookup(); /*check(lookup, "glLoadIdentity"); check(lookup, "gluLookAt");*/ // use reflection to load all classes matching "opengl.ubuntu.v20.constant$[\d+].java" // String packageName = "opengl.ubuntu.v20"; String classPattern = "constants\\$(\\d+)"; String nativeFunctionPatternFilter = "gl.*"; printLinkStatus(lookup, packageName, classPattern, nativeFunctionPatternFilter, Link.MISSING); } public static void printLinkStatus(SymbolLookup lookup, String packageName, String classPattern, String nativeFunctionPatternFilter, Link linkStatus) throws ClassNotFoundException, IOException, IllegalAccessException { Class[] classes = getClasses(packageName); System.out.println("----------------------------------------------------------------"); System.out.println("Following native functions have link status : " + linkStatus); System.out.println("----------------------------------------------------------------"); for(Class clazz: classes){ // only check classes matching pattern if(Pattern.matches(classPattern, clazz.getSimpleName())){ printLinkStatus(lookup, clazz, nativeFunctionPatternFilter, linkStatus); } } System.out.println("----------------------------------------------------------------"); System.out.println("Done checking link status"); } public static void printLinkStatus(SymbolLookup lookup, Class clazz, String nativeFunctionPatternFilter, Link linkStatus) throws IllegalAccessException { Field[] fields = clazz.getDeclaredFields(); for(Field field: fields){ // Only check MethodHandle fields in this class if(field.getType().equals(MethodHandle.class)){ int cutNameAt = field.getName().indexOf("$"); if(cutNameAt>0){ // remove the trailing $MH from field name to get the original // method name as given in header file String generatedMethod = field.getName().substring(0, cutNameAt); if(Pattern.matches(nativeFunctionPatternFilter, generatedMethod)){ //System.out.println(generatedMethod); printLinkStatus(lookup, clazz, field, generatedMethod, linkStatus); } } } } } public static void printLinkStatus(SymbolLookup lookup, Class clazz, Field field, String generatedMethod, Link linkStatus) throws IllegalAccessException { if(lookup!=null) { Optional memAddress = lookup.lookup(generatedMethod); if (memAddress.isEmpty() && Link.MISSING.equals(linkStatus)) { System.out.println(generatedMethod + ":\t (" + clazz.getSimpleName() + "." + field.getName() + ") link is MISSING"); } if (memAddress.isPresent() && Link.SUCCESS.equals(linkStatus)) { System.out.println(generatedMethod + ":\t (" + memAddress.get() + ") is linked"); } } else { field.setAccessible(true); // bypass package protected field Object fieldValue = field.get(null); if (fieldValue == null && Link.MISSING.equals(linkStatus)) { System.out.println(generatedMethod + ":\t (" + clazz.getSimpleName() + "." + field.getName() + ") link is MISSING"); } if (fieldValue != null && Link.SUCCESS.equals(linkStatus)) { System.out.println(generatedMethod + ":\t (" + clazz.getSimpleName() + "." + field.getName() + ") is linked"); } } } enum Link{ SUCCESS, MISSING } public static void check(SymbolLookup lookup, String function){ System.out.println(function + ":" + lookup.lookup(function)); } ///////////////////////////////////////////////////// // // LOAD ALL CLASS FROM CLASSLOADER // ///////////////////////////////////////////////////// public static Class[] getClasses(String packageName) throws ClassNotFoundException, IOException { ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); assert classLoader != null; String path = packageName.replace('.', '/'); Enumeration resources = classLoader.getResources(path); List dirs = new ArrayList(); while (resources.hasMoreElements()) { URL resource = resources.nextElement(); dirs.add(new File(resource.getFile())); } ArrayList classes = new ArrayList(); for (File directory : dirs) { classes.addAll(findClasses(directory, packageName)); } return classes.toArray(new Class[classes.size()]); } /** * Recursive method used to find all classes in a given directory and subdirs. * * @param directory The base directory * @param packageName The package name for classes found inside the base directory * @return The classes * @throws ClassNotFoundException */ private static List findClasses(File directory, String packageName) throws ClassNotFoundException { List classes = new ArrayList(); if (!directory.exists()) { return classes; } File[] files = directory.listFiles(); for (File file : files) { if (file.isDirectory()) { assert !file.getName().contains("."); classes.addAll(findClasses(file, packageName + "." + file.getName())); } else if (file.getName().endsWith(".class")) { classes.add(Class.forName(packageName + '.' + file.getName().substring(0, file.getName().length() - 6))); } } return classes; } } Sent with ProtonMail Secure Email. ??????? Original Message ??????? Le lundi 22 novembre 2021 ? 13:23, Maurizio Cimadamore a ?crit : > I see what you mean. > > Unfortunately, having too strict of a behavior at runtime (e.g. fail > > early when a non-existing function is detected) might also be overly > > strict. There are many cases where the library is 99% there, except for > > one or two problematic functions (which might be delivered as macros on > > some platforms, but not in others). If these functions are never called, > > failing eagerly might seem overly harsh. > > Possible options are to use some kind of SPI to allow clients to > > override function lookup - but honestly, it seems a very complex > > solution. E.g. in your case you can probably tweak RuntimeHelper sources > > to fail early if a native symbol is not found. > > Maurizio > > On 22/11/2021 12:08, Martin Pernollet wrote: > > > Hi Maurizio, > > > > Maybe this would be more handy to run this from the program using the binding : providing the libs to JExtract has the drawback to tidying the generated library to the developer lib path. In the future I woule like not use the -l option to prevent JExtract from generating the System.load and System.loadLibrary, and write this lib loading code on the user side. > > > > Example use case that I got working : I generated bindings from a Mac 11.4 computer which has the lib at a given path /a/b/c. I ran from a Mac 10.15 and noticed it works perfectly by just modifying the path to the GL libs at /d/e/f. > > > > If I was wrong entering /d/e/g at runtime, I would like to detect unmapped functions. > > > > Cheers > > > > Sent with ProtonMail Secure Email. > > > > ??????? Original Message ??????? > > > > Le lundi 22 novembre 2021 ? 11:41, Maurizio Cimadamore maurizio.cimadamore at oracle.com a ?crit : > > > > > Hi Martin, > > > > > > we used to have a check similar to the one you describe in an earlier > > > > > > version of jextract (e.g. when `-l` was specified, we would check that > > > > > > functions/global vars were emitted in said libs). We can probably re-add > > > > > > such a check. > > > > > > Maurizio > > > > > > On 21/11/2021 17:39, Martin Pernollet wrote: > > > > > > > Hi, > > > > > > > > The UnsatisfiedLinkError was triggered while invoking a method relying on a null method handle. > > > > > > > > When invoking jextract, I provided an include dir with multiple header files (usr/include/GL) but an incomplete list of libraries. The code is generated correctly and the user of this generated code don't see any problem at compile time. However, when running the program, glut_h will only map a subset of the generated method handles to the native libs. > > > > > > > > It would be convenient to get warnings about it when the program starts. Would you recommend a way to iterate over all generated method handles to check those that are null? > > > > > > > > /usr/lib/jvm/jdk-17-panama/bin/jextract -d ./src/main/java/ --source -t opengl.ubuntu.v20 \ > > > > > > > > -lGL \ > > > > > > > > -l/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 \ > > > > > > > > -l/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1 \ << that one was missing > > > > > > > > -I /usr/include/GL \ > > > > > > > > -C-F/usr/include/GL \ > > > > > > > > /usr/include/GL/glut.h > > > > > > > > public class glut_h extends glut_h_6 { > > > > > > > > static { > > > > System.loadLibrary("GL"); > > > > System.load("/usr/lib/x86_64-linux-gnu/libglut.so.3.9.0"); > > > > System.load("/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1"); // fixing jextract lib list let glut_h map the metod handle to the native libs > > > > } > > > > > > > > > > > > Cheers, > > > > > > > > Martin > > > > > > > > ??????? Original Message ??????? > > > > > > > > Le lundi 15 novembre 2021 ? 11:43, Maurizio Cimadamore maurizio.cimadamore at oracle.com a ?crit : > > > > > > > > > Hi, > > > > > > > > > > from the top of my head, this looks like an exception thrown while you > > > > > > > > > > are executing an upcall. And it also looks like you are missing some of > > > > > > > > > > the latest patches which will generate a "normal" stack trace. So you > > > > > > > > > > only see the exception name (UnsatisfiedLink). > > > > > > > > > > As a general rule, if an exception occurs when an upcall is executing, > > > > > > > > > > only option is to exit the Java program, so that we don't leave the > > > > > > > > > > native code in a potentially bad state. > > > > > > > > > > But more recent releases of the linker API do a better job at presenting > > > > > > > > > > this as an "exception" (although one that cannot be caught) rather than > > > > > > > > > > a blunt crash. > > > > > > > > > > If you can't update to a newer build, I'd look into all upcall code, > > > > > > > > > > looking for all pieces of code which might do System.load/loadLibrary. > > > > > > > > > > Maurizio > > > > > > > > > > On 15/11/2021 07:33, Martin Pernollet wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I am now on Ubuntu. The original teapot sample is working (just > > > > > > > > > > > > required to change glutDisplayFunc$func to glutDisplayFunc$callback). > > > > > > > > > > > > I got an UnstasfiedLinkException with other programs. I wonder if you > > > > > > > > > > > > have a suggestion to help me understand my mistake? LDD command does > > > > > > > > > > > > not help. Like for the NPE, we lack a bit of info for debugging. > > > > > > > > > > > > Console says > > > > > > > > > > > > Uncaught exception: > > > > > > > > > > > > java.lang.UnsatisfiedLinkError > > > > > > > > > > > > {0x0000000091ac9b58} - klass: 'java/lang/UnsatisfiedLinkError' > > > > > > > > > > > > A fatal error has been detected by the Java Runtime Environment: > > > > > > ================================================================ > > > > > > > > > > > > #? Internal Error (universalUpcallHandler.cpp:113), pid=33668, tid=33677 > > > > > > > > > > > > #? Error: ShouldNotReachHere() > > > > > > > > > > > > Core dump says (see attached the complete core dump file) > > > > > > > > > > > > Current thread (0x00007f5d580268c0):? JavaThread "main" > > > > > > > > > > > > [_thread_in_Java, id=35593, stack(0x00007f5d5f59e000,0x00007f5d5f69f000)] > > > > > > > > > > > > Stack: [0x00007f5d5f59e000,0x00007f5d5f69f000], > > > > > > > > > > > > sp=0x00007f5d5f69c8b0,? free space=1018k > > > > > > > > > > > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > > > > > > > > > > > > C=native code) > > > > > > > > > > > > V? [libjvm.so+0xd993a3] > > > > > > > > > > > > ProgrammableUpcallHandler::handle_uncaught_exception(oopDesc*)+0x43 > > > > > > > > > > > > v? ~BufferBlob::panama_upcall_stub > > > > > > > > > > > > C? [libglut.so.3.9.0+0x20895]? glutMainLoopEvent+0x2a5 > > > > > > > > > > > > Register to memory mapping: > > > > > > > > > > > > RAX=0x00007f5d60cc4000 points into unknown readable memory: > > > > > > > > > > > > 0x0000000000000058 | 58 00 00 00 00 00 00 00 > > > > > > > > > > > > RBX=0x00007f5d4184556a is at code_begin+842 in > > > > > > > > > > > > [CodeBlob (0x00007f5d41845190)] > > > > > > > > > > > > Framesize: 0 > > > > > > > > > > > > BufferBlob (0x00007f5d41845190) used for panama_upcall_stub > > > > > > > > > > > > RCX=0x000000000000000a is an unknown value > > > > > > > > > > > > RDX=0x0 is NULL > > > > > > > > > > > > RSP=0x00007f5d5f69c8b0 is pointing into the stack for thread: > > > > > > > > > > > > 0x00007f5d580268c0 > > > > > > > > > > > > RBP=0x00007f5d5f69c8c0 is pointing into the stack for thread: > > > > > > > > > > > > 0x00007f5d580268c0 > > > > > > > > > > > > RSI=0x0000000000000071 is an unknown value > > > > > > > > > > > > RDI=0x00007f5d606f6108: in > > > > > > > > > > > > /usr/lib/jvm/jdk-17-panama/lib/server/libjvm.so at 0x00007f5d5f7f9000 > > > > > > > > > > > > R8 =0x0 is NULL > > > > > > > > > > > > R9 =0x00007f5d5f69c8a0 is pointing into the stack for thread: > > > > > > > > > > > > 0x00007f5d580268c0 > > > > > > > > > > > > R10=0x0 is NULL > > > > > > > > > > > > R11=0x0 is NULL > > > > > > > > > > > > R12=0x0000000091d82828 is an oop: java.lang.UnsatisfiedLinkError > > > > > > > > > > > > {0x0000000091d82828} - klass: 'java/lang/UnsatisfiedLinkError' > > > > > > > > > > > > R13=0x00007f5d1c42fbdc is pointing into metadata > > > > > > > > > > > > R14=0x00007f5d5f69c8c8 is pointing into the stack for thread: > > > > > > > > > > > > 0x00007f5d580268c0 > > > > > > > > > > > > R15=0x00007f5d580268c0 is a thread > > > > > > > > > > > > I verified with LDD if the lib I am linking to has dependencies > > > > > > > > > > > > problem but it seams to be ok. > > > > > > > > > > > > ldd --verbose /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 > > > > > > > > > > > > linux-vdso.so.1 (0x00007ffc37dcd000) > > > > > > > > > > > > libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007effdf322000) > > > > > > > > > > > > libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007effdf1e5000) > > > > > > > > > > > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007effdf096000) > > > > > > > > > > > > libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6 (0x00007effdf084000) > > > > > > > > > > > > libXxf86vm.so.1 => /lib/x86_64-linux-gnu/libXxf86vm.so.1 > > > > > > > > > > > > (0x00007effdf07d000) > > > > > > > > > > > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007effdee8b000) > > > > > > > > > > > > libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 > > > > > > > > > > > > (0x00007effdedd1000) > > > > > > > > > > > > libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007effded9d000) > > > > > > > > > > > > libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007effded73000) > > > > > > > > > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007effded6d000) > > > > > > > > > > > > /lib64/ld-linux-x86-64.so.2 (0x00007effdf608000) > > > > > > > > > > > > libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007effded58000) > > > > > > > > > > > > libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007effded50000) > > > > > > > > > > > > libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007effded48000) > > > > > > > > > > > > libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007effded2e000) > > > > > > > > > > > > Version information: > > > > > > > > > > > > /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0: > > > > > > > > > > > > libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libGL.so.1: > > > > > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libX11.so.6: > > > > > > > > > > > > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > > > > > > > > > > > > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.26) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libm.so.6: > > > > > > > > > > > > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libXi.so.6: > > > > > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libXxf86vm.so.1: > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libc.so.6: > > > > > > > > > > > > ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 > > > > > > > > > > > > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libGLdispatch.so.0: > > > > > > > > > > > > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > > > > > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libGLX.so.0: > > > > > > > > > > > > libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2 > > > > > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libxcb.so.1: > > > > > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libdl.so.2: > > > > > > > > > > > > ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 > > > > > > > > > > > > libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libXext.so.6: > > > > > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libXau.so.6: > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libXdmcp.so.6: > > > > > > > > > > > > libbsd.so.0 (LIBBSD_0.2) => /lib/x86_64-linux-gnu/libbsd.so.0 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > /lib/x86_64-linux-gnu/libbsd.so.0: > > > > > > > > > > > > libc.so.6 (GLIBC_2.25) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.16) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.8) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 > > > > > > > > > > > > libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 From paul.sandoz at oracle.com Mon Nov 22 17:56:25 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 22 Nov 2021 17:56:25 +0000 Subject: How to validate the successfulness of the c2 compiler in generating vectorized assembly In-Reply-To: References: Message-ID: <305A5B75-77BA-46D4-92CB-E04565C688BF@oracle.com> Hi Robbe, My recommendation is to write a JMH benchmark and then print the hot assembly. Here?s an example: https://github.com/PaulSandoz/vector-api-dev-live-10-2021/blob/main/src/main/java/jmh/BytesHashcode.java#L244 You can also use the diagnostic flag -XX:+PrintIntrinsics which will output when intensification fails. Array allocations suggest that vector values are being boxed. It?s hard to provide more guidance without seeing more code and knowing what version you are using. If it's possible to share I might be able to help. Over time as we close more gaps in the Vector API implementation I hope that this kind of analysis will be less needed. Paul. > On Nov 22, 2021, at 9:03 AM, Robbe Pincket wrote: > > Hi > > Recently, A coworker converted part of our codebase to use the new incubating vector api. And although a noticable increase in performance was measured, the allocation rate under even mild stress of the system has skyrocketed to 1.3 gb/s, due to the need of creating temporary arrays. After a partial rewrite, to avoid most of those allocations or replace a few double arrays to short or byte arrays, I was expecting this rate to significantly drop. This did not seem to happen. Instead there are many more array allocations happening in the creation of the vectors and vector masks themselves. On top of that, the code seems to now be noticable slower than the original code. It seems that the c2 compiler is failing to generate any vectorized code. > > So here is my question: What is the best way to validate whether the c2 compiler is actually using vectorized opcodes, and if not, get feedback from the compiler on why it fails to do so. > > Thanks in advance > Robbe Pincket From njian at openjdk.java.net Tue Nov 23 02:41:01 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 23 Nov 2021 02:41:01 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:vectorIntrinsics+compress In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 21:13:23 GMT, Sandhya Viswanathan wrote: > Merge vectorIntrinsics+compress into vectorIntrinsics. > @nsjian need your help to update test/hotspot/gtest/aarch64/asmtest.out.h. > > Best Regards, > Sandhya @sviswa7 Sorry for missing the review. I will regenerate the test file. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/167 From njian at openjdk.java.net Tue Nov 23 02:46:39 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 23 Nov 2021 02:46:39 GMT Subject: [vectorIntrinsics] RFR: Update asmtest.out.h due to incorrect merge Message-ID: Regenerated the file. ------------- Commit messages: - Update asmtest.out.h due to incorrect merge. Changes: https://git.openjdk.java.net/panama-vector/pull/168/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=168&range=00 Stats: 105 lines in 1 file changed: 0 ins; 0 del; 105 mod Patch: https://git.openjdk.java.net/panama-vector/pull/168.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/168/head:pull/168 PR: https://git.openjdk.java.net/panama-vector/pull/168 From eliu at openjdk.java.net Tue Nov 23 02:57:34 2021 From: eliu at openjdk.java.net (Eric Liu) Date: Tue, 23 Nov 2021 02:57:34 GMT Subject: [vectorIntrinsics] RFR: Update asmtest.out.h due to incorrect merge In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 02:39:21 GMT, Ningsheng Jian wrote: > Regenerated the file. LGTM. ------------- Marked as reviewed by eliu (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/168 From njian at openjdk.java.net Tue Nov 23 03:03:25 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 23 Nov 2021 03:03:25 GMT Subject: [vectorIntrinsics] RFR: Update asmtest.out.h due to incorrect merge In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 02:53:50 GMT, Eric Liu wrote: >> Regenerated the file. > > LGTM. Thanks for the quick review! @theRealELiu ------------- PR: https://git.openjdk.java.net/panama-vector/pull/168 From njian at openjdk.java.net Tue Nov 23 03:03:26 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 23 Nov 2021 03:03:26 GMT Subject: [vectorIntrinsics] Integrated: Update asmtest.out.h due to incorrect merge In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 02:39:21 GMT, Ningsheng Jian wrote: > Regenerated the file. This pull request has now been integrated. Changeset: fd3666a3 Author: Ningsheng Jian URL: https://git.openjdk.java.net/panama-vector/commit/fd3666a35293ad86090758600cae2c9665af99ca Stats: 105 lines in 1 file changed: 0 ins; 0 del; 105 mod Update asmtest.out.h due to incorrect merge Reviewed-by: eliu ------------- PR: https://git.openjdk.java.net/panama-vector/pull/168 From martin.pernollet at protonmail.com Tue Nov 23 11:17:22 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Tue, 23 Nov 2021 11:17:22 +0000 Subject: Generated code differences accross OS Message-ID: Hi, There is difference in code generated on Ubuntu and MacOS, e.g. : glutReshapeFunc$func on MacOS glutReshapeFunc$callback on Ubuntu Will this remain as is in future versions of JExtract? If this is intentional, what is the reason for this? This is a bit annoying for generating multiplatform bindings because this will requires writing (or generating) a wrapper on the generated code. I am interested if someone knows a page discussing all differences that may arise in code generated on different OS. Thanks, Martin From maurizio.cimadamore at oracle.com Tue Nov 23 12:00:12 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 23 Nov 2021 12:00:12 +0000 Subject: Generated code differences accross OS In-Reply-To: References: Message-ID: AFAIK, the only difference is that, depending on the glut library in use, the parameter name is different, and the resulting function pointer factory is also different (because we use the parameter name to infer a good factory name). I think that, as you point out, this naming strategy is a little unstable, as small differences (e.g. parameter names) end up with incompatible bindings. We do not have a page listing these kind of issues (we need to improve jextract documentation, we are aware of that). On top of my mind, differences can include: * type mismatches (e.g. `long` means 32 bits on windows, and 64 bits on linux) * padding in structs might vary (largely because of the above) * in some platforms some additional functions/struct members might be defined * macros vs. function differences - e.g. a function might be a real shared library function on one platform/OS and just a macro in another Assuming the library is written in a portable way (e.g. mainly avoids to refer to types such as `long`), things should work relatively well - but of course this is C and it is hard to generalize too much. In other words, your mileage when reusing same extracted sources across platforms/os is gonna vary, regardless of how smart jextract naming choices are. That said, if clients generate new bindings for each platforms, I think jextract should try and depend only on public API names - otherwise it becomes harder for clients of bindings (since a member can have name X in one platform/OS and name Y in another). So, assuming we fix this, what would be a good naming strategy for callback factories? If we don't want to depend on the parameter name, an alternative could be: $upcall or, if the same function has more than one: $upcall$ where `pos` is the callback parameter index in the function signature. Would that be satisfactory? Maurizio On 23/11/2021 11:17, Martin Pernollet wrote: > Hi, > > There is difference in code generated on Ubuntu and MacOS, e.g. : > > glutReshapeFunc$func on MacOS > glutReshapeFunc$callback on Ubuntu > > Will this remain as is in future versions of JExtract? If this is intentional, what is the reason for this? > > This is a bit annoying for generating multiplatform bindings because this will requires writing (or generating) a wrapper on the generated code. > > I am interested if someone knows a page discussing all differences that may arise in code generated on different OS. > > Thanks, > > Martin From martin.pernollet at protonmail.com Tue Nov 23 14:08:17 2021 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Tue, 23 Nov 2021 14:08:17 +0000 Subject: Generated code differences accross OS In-Reply-To: References: Message-ID: Hi, You are completely right. I started on MacOS with the OpenGL sample based on GLUT [1], and then continued on Windows and Ubuntu with FREEGLUT as suggested [2]. The API are almost similar, but the naming indeed changes (and freeglut has few additional utility not provided by GLUT for information). After installing freeglut on MacOS, I can see that the naming is consistent. I'll try working with freeglut on Mac. If this works properly I can PR that change on the demo repo you made available on Github. This would avoid clarifying this difference here that I missed for a while :D [3]. I don't think this problem should arise again for anyone using the same headers so maybe overriding callback names is not important... unless a header file switches parameter names according to target platform - which would be really weird :) Beside this, if another use case justify renaming, the parameter naming you propose sounds perfect. Thank you very much for taking time to clarify! [1] https://github.com/sundararajana/panama-jextract-samples/blob/master/opengl/compilesource.sh#L1 [2] https://github.com/sundararajana/panama-jextract-samples/blob/master/opengl/compile_windows.ps1#L11 [3] https://github.com/sundararajana/panama-jextract-samples/blob/master/opengl/README.md ??????? Original Message ??????? Le mardi 23 novembre 2021 ? 13:00, Maurizio Cimadamore a ?crit : > AFAIK, the only difference is that, depending on the glut library in > > use, the parameter name is different, and the resulting function pointer > > factory is also different (because we use the parameter name to infer a > > good factory name). > > I think that, as you point out, this naming strategy is a little > > unstable, as small differences (e.g. parameter names) end up with > > incompatible bindings. > > We do not have a page listing these kind of issues (we need to improve > > jextract documentation, we are aware of that). On top of my mind, > > differences can include: > > - type mismatches (e.g. `long` means 32 bits on windows, and 64 bits on > > linux) > - padding in structs might vary (largely because of the above) > - in some platforms some additional functions/struct members might be > > defined > - macros vs. function differences - e.g. a function might be a real > > shared library function on one platform/OS and just a macro in another > > Assuming the library is written in a portable way (e.g. mainly avoids to > > refer to types such as `long`), things should work relatively well - but > > of course this is C and it is hard to generalize too much. In other > > words, your mileage when reusing same extracted sources across > > platforms/os is gonna vary, regardless of how smart jextract naming > > choices are. > > That said, if clients generate new bindings for each platforms, I think > > jextract should try and depend only on public API names - otherwise it > > becomes harder for clients of bindings (since a member can have name X > > in one platform/OS and name Y in another). > > So, assuming we fix this, what would be a good naming strategy for > > callback factories? If we don't want to depend on the parameter name, an > > alternative could be: > > $upcall > > or, if the same function has more than one: > > $upcall$ > > where `pos` is the callback parameter index in the function signature. > > Would that be satisfactory? > > Maurizio > > On 23/11/2021 11:17, Martin Pernollet wrote: > > > Hi, > > > > There is difference in code generated on Ubuntu and MacOS, e.g. : > > > > glutReshapeFunc$func on MacOS > > > > glutReshapeFunc$callback on Ubuntu > > > > Will this remain as is in future versions of JExtract? If this is intentional, what is the reason for this? > > > > This is a bit annoying for generating multiplatform bindings because this will requires writing (or generating) a wrapper on the generated code. > > > > I am interested if someone knows a page discussing all differences that may arise in code generated on different OS. > > > > Thanks, > > > > Martin From mcimadamore at openjdk.java.net Tue Nov 23 14:13:28 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 23 Nov 2021 14:13:28 GMT Subject: [foreign-jextract] RFR: 8277645: TreeMaker should not call type() on pointer types too early Message-ID: This patch fixes a couple of callsites in TreeMaker which were calling `DelegatedType::type`. `DelegatedType` is a common supertype for both typedef types and pointer types. The reason why `TreeMaker` calls that method is to recover the *canonical* type of a typedef. Unfortunately, as `TreeMaker` doesn't check the delegated type kind, it can sometime call `type()` on a delegated type whose kind is `POINTER`. The way in which the jextract parser is setup is such that pointee types can only be accessed *after* parsing has completed. This issue only occurs under very rare circumstances, that is when a type qualifier (other than the usual ones, such as `const`) is used on a pointer typedef - such as `__ptr64`. In such cases, the clang AST sees an `AttributedType` and not a `QualifiedType`, which throws our parsing logic off-guard. The solution is to check for the delegated type kind before attempting to call `type()`, and only call it when its kind is `TYPEDEF`. To test this I used the special clang flag `-fms-extensions` which allows to use the MS extensions even on Linux/Mac. ------------- Commit messages: - Fix TreeMaker not to call type() on potentially unresolved pointers Changes: https://git.openjdk.java.net/panama-foreign/pull/616/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=616&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277645 Stats: 60 lines in 3 files changed: 50 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/616.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/616/head:pull/616 PR: https://git.openjdk.java.net/panama-foreign/pull/616 From jvernee at openjdk.java.net Tue Nov 23 14:21:40 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 23 Nov 2021 14:21:40 GMT Subject: [foreign-jextract] RFR: 8277645: TreeMaker should not call type() on pointer types too early In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 14:05:34 GMT, Maurizio Cimadamore wrote: > This patch fixes a couple of callsites in TreeMaker which were calling `DelegatedType::type`. > > `DelegatedType` is a common supertype for both typedef types and pointer types. The reason why `TreeMaker` calls that method is to recover the *canonical* type of a typedef. > > Unfortunately, as `TreeMaker` doesn't check the delegated type kind, it can sometime call `type()` on a delegated type whose kind is `POINTER`. The way in which the jextract parser is setup is such that pointee types can only be accessed *after* parsing has completed. > > This issue only occurs under very rare circumstances, that is when a type qualifier (other than the usual ones, such as `const`) is used on a pointer typedef - such as `__ptr64`. In such cases, the clang AST sees an `AttributedType` and not a `QualifiedType`, which throws our parsing logic off-guard. > > The solution is to check for the delegated type kind before attempting to call `type()`, and only call it when its kind is `TYPEDEF`. To test this I used the special clang flag `-fms-extensions` which allows to use the MS extensions even on Linux/Mac. test/jdk/tools/jextract/TestAttributedPointerTypedef.java line 29: > 27: * @library /test/lib > 28: * @build BadBitfieldTest > 29: * @run testng/othervm --enable-native-access=jdk.incubator.jextract BadBitfieldTest This is not running the right test class it seems. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/616 From mcimadamore at openjdk.java.net Tue Nov 23 14:34:07 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 23 Nov 2021 14:34:07 GMT Subject: [foreign-jextract] RFR: 8277645: TreeMaker should not call type() on pointer types too early [v2] In-Reply-To: References: Message-ID: <1TIzFqywc6jRjdZnbYnx8SZ9r1GJeNvR0tBVn0GccnA=.ffa35f77-aa0e-465d-a1dd-4622222488cc@github.com> > This patch fixes a couple of callsites in TreeMaker which were calling `DelegatedType::type`. > > `DelegatedType` is a common supertype for both typedef types and pointer types. The reason why `TreeMaker` calls that method is to recover the *canonical* type of a typedef. > > Unfortunately, as `TreeMaker` doesn't check the delegated type kind, it can sometime call `type()` on a delegated type whose kind is `POINTER`. The way in which the jextract parser is setup is such that pointee types can only be accessed *after* parsing has completed. > > This issue only occurs under very rare circumstances, that is when a type qualifier (other than the usual ones, such as `const`) is used on a pointer typedef - such as `__ptr64`. In such cases, the clang AST sees an `AttributedType` and not a `QualifiedType`, which throws our parsing logic off-guard. > > The solution is to check for the delegated type kind before attempting to call `type()`, and only call it when its kind is `TYPEDEF`. To test this I used the special clang flag `-fms-extensions` which allows to use the MS extensions even on Linux/Mac. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix bogus references to other test ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/616/files - new: https://git.openjdk.java.net/panama-foreign/pull/616/files/6ec7b28d..24f0fe43 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=616&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=616&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/616.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/616/head:pull/616 PR: https://git.openjdk.java.net/panama-foreign/pull/616 From jvernee at openjdk.java.net Tue Nov 23 14:41:42 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 23 Nov 2021 14:41:42 GMT Subject: [foreign-jextract] RFR: 8277645: TreeMaker should not call type() on pointer types too early [v2] In-Reply-To: <1TIzFqywc6jRjdZnbYnx8SZ9r1GJeNvR0tBVn0GccnA=.ffa35f77-aa0e-465d-a1dd-4622222488cc@github.com> References: <1TIzFqywc6jRjdZnbYnx8SZ9r1GJeNvR0tBVn0GccnA=.ffa35f77-aa0e-465d-a1dd-4622222488cc@github.com> Message-ID: On Tue, 23 Nov 2021 14:34:07 GMT, Maurizio Cimadamore wrote: >> This patch fixes a couple of callsites in TreeMaker which were calling `DelegatedType::type`. >> >> `DelegatedType` is a common supertype for both typedef types and pointer types. The reason why `TreeMaker` calls that method is to recover the *canonical* type of a typedef. >> >> Unfortunately, as `TreeMaker` doesn't check the delegated type kind, it can sometime call `type()` on a delegated type whose kind is `POINTER`. The way in which the jextract parser is setup is such that pointee types can only be accessed *after* parsing has completed. >> >> This issue only occurs under very rare circumstances, that is when a type qualifier (other than the usual ones, such as `const`) is used on a pointer typedef - such as `__ptr64`. In such cases, the clang AST sees an `AttributedType` and not a `QualifiedType`, which throws our parsing logic off-guard. >> >> The solution is to check for the delegated type kind before attempting to call `type()`, and only call it when its kind is `TYPEDEF`. To test this I used the special clang flag `-fms-extensions` which allows to use the MS extensions even on Linux/Mac. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix bogus references to other test Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/616 From mcimadamore at openjdk.java.net Tue Nov 23 14:46:33 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 23 Nov 2021 14:46:33 GMT Subject: [foreign-jextract] Integrated: 8277645: TreeMaker should not call type() on pointer types too early In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 14:05:34 GMT, Maurizio Cimadamore wrote: > This patch fixes a couple of callsites in TreeMaker which were calling `DelegatedType::type`. > > `DelegatedType` is a common supertype for both typedef types and pointer types. The reason why `TreeMaker` calls that method is to recover the *canonical* type of a typedef. > > Unfortunately, as `TreeMaker` doesn't check the delegated type kind, it can sometime call `type()` on a delegated type whose kind is `POINTER`. The way in which the jextract parser is setup is such that pointee types can only be accessed *after* parsing has completed. > > This issue only occurs under very rare circumstances, that is when a type qualifier (other than the usual ones, such as `const`) is used on a pointer typedef - such as `__ptr64`. In such cases, the clang AST sees an `AttributedType` and not a `QualifiedType`, which throws our parsing logic off-guard. > > The solution is to check for the delegated type kind before attempting to call `type()`, and only call it when its kind is `TYPEDEF`. To test this I used the special clang flag `-fms-extensions` which allows to use the MS extensions even on Linux/Mac. This pull request has now been integrated. Changeset: c15cb9c1 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/c15cb9c11e03c7552d2143273959acac30969db7 Stats: 60 lines in 3 files changed: 50 ins; 5 del; 5 mod 8277645: TreeMaker should not call type() on pointer types too early Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/616 From psandoz at openjdk.java.net Tue Nov 23 21:43:04 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 23 Nov 2021 21:43:04 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master Message-ID: Merge master into `vectorIntrinsics`. Conflicts were resolved in `node.hpp` @nsjian conflicts were found test/hotspot/gtest/aarch64/asmtest.out.h so I just selected that in `vectorIntrinsics`. Can you please send me updates for that? ------------- Commit messages: - Merge branch 'master' into vectorIntrinsics-merge-with-master - 8271623: Omit enclosing instance fields from inner classes that don't use it - 8277451: java.lang.reflect.Field::set on static field with invalid argument type should throw IAE - 8277350: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java times out - 8268725: jshell does not support the --enable-native-access option - 8261847: performance of java.lang.Record::toString should be improved - 8254108: ciReplay: Support incremental inlining - 8277649: [BACKOUT] JDK-8277507 Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures - 8272042: java.util.ImmutableCollections$Map1 and MapN should not be @ValueBased - 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper - ... and 92 more: https://git.openjdk.java.net/panama-vector/compare/fd3666a3...0bdd57c5 The webrevs contain the adjustments done while merging with regards to each parent branch: - vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=169&range=00.0 - panama-vector:master: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=169&range=00.1 Changes: https://git.openjdk.java.net/panama-vector/pull/169/files Stats: 12466 lines in 416 files changed: 9847 ins; 1235 del; 1384 mod Patch: https://git.openjdk.java.net/panama-vector/pull/169.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/169/head:pull/169 PR: https://git.openjdk.java.net/panama-vector/pull/169 From paul.sandoz at oracle.com Tue Nov 23 23:30:17 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 23 Nov 2021 23:30:17 +0000 Subject: Support for Matrix Extension In-Reply-To: References: Message-ID: <63C088A8-445C-48C7-9F7D-00DC613661A3@oracle.com> Hi St?phane, Thanks for sharing that information. Relatedly, the auto-vectorizer was enhanced to support some VNNI instructions: https://bugs.openjdk.java.net/browse/JDK-8214751 And, we are exploring half float support here: https://github.com/openjdk/panama-vector/pull/164 We are aware of the AMX extensions but have not given much deep thought into how it might fit into the Vector API or be some separate abstraction belonging to the same larger family. I was not aware of the similar functionality for ARM. The AMX tile configuration management could make it challenging, as if there is a session of tile-based computation with tile sizes known in advance for some computation. I think one primary use-case for AMX is to replace vector micro-kernels in a highly optimized gemm-like operations, where data movement and package are equally important. Paul. > On Nov 19, 2021, at 7:18 AM, St?phane Dubedat wrote: > > Intel next server CPU iteration Sapphire rappids will introduce a new x86 > extension name AMX. > This potentially disruptive extension allows for hardware accelerated SIMD > Matrix operations! > https://fuse.wikichip.org/news/3600/the-x86-advanced-matrix-extension-amx-brings-matrix-operations-to-debut-with-sapphire-rapids/ > https://en.wikichip.org/wiki/x86/amx > > Note that ARM also has an analogue extension: > https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/scalable-matrix-extension-armv9-a-architecture > > So > 1) The vector API should expose an explicit API for leveraging those new, > majorly useful, SIMD instructions > 2) The JVM/Vector API could leverage sometimes those instructions > automatically even when not specified by the user, if supported at runtime > and detecting patterns of matrices operations? > > Maybe this could be useful for more things that matrix operations such as N > dimensional arrays in general? -> > https://github.com/eclipse/deeplearning4j/tree/master/nd4j > Ndarray are very useful as can be seen by their widespread use on the > Python ecosystem through Numpy > see also this SIMD version https://github.com/JetBrains-Research/viktor From njian at openjdk.java.net Wed Nov 24 01:23:24 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 24 Nov 2021 01:23:24 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master In-Reply-To: References: Message-ID: <0OA2_ZyW6nWMd-gpaZNWB9ar2v_n_Elpb9BW0ngZuks=.1fcf7a45-ece2-4ac6-aa71-e29d26021328@github.com> On Tue, 23 Nov 2021 21:36:16 GMT, Paul Sandoz wrote: > Merge master into `vectorIntrinsics`. > > Conflicts were resolved in `node.hpp` > > @nsjian conflicts were found test/hotspot/gtest/aarch64/asmtest.out.h so I just selected that in `vectorIntrinsics`. Can you please send me updates for that? I have regenerated asmtest.out.h and send it to you. Otherwise, looks good to me. ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/169 From psandoz at openjdk.java.net Wed Nov 24 15:53:07 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 24 Nov 2021 15:53:07 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v2] In-Reply-To: References: Message-ID: > Merge master into `vectorIntrinsics`. > > Conflicts were resolved in `node.hpp` > > @nsjian conflicts were found test/hotspot/gtest/aarch64/asmtest.out.h so I just selected that in `vectorIntrinsics`. Can you please send me updates for that? Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Update ASM test. ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/169/files - new: https://git.openjdk.java.net/panama-vector/pull/169/files/0bdd57c5..e7acea47 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=169&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=169&range=00-01 Stats: 139 lines in 1 file changed: 50 ins; 0 del; 89 mod Patch: https://git.openjdk.java.net/panama-vector/pull/169.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/169/head:pull/169 PR: https://git.openjdk.java.net/panama-vector/pull/169 From maurizio.cimadamore at oracle.com Wed Nov 24 16:25:09 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 24 Nov 2021 16:25:09 +0000 Subject: Integrated: 8275063: Implementation of Foreign Function & Memory API (Second incubator) In-Reply-To: <14b442fb-0612-2664-6e90-e0cbdd7c0203@gmail.com> References: <14b442fb-0612-2664-6e90-e0cbdd7c0203@gmail.com> Message-ID: <40cf3777-85fc-5fce-f210-049afdfa6ed5@oracle.com> I think this discussion should go either on core-libs or on panama-dev. build-dev is not the place for it. I'm addding panama-dev - and then I'll reply from there. Maurizio On 24/11/2021 16:15, Ty Young wrote: > Was this code actually reviewed or even used/tested at all? All "Java" > ValueLayouts have an 8-bit alignment, even if they are 2-byte, 4-byte, > or 8-byte in size: > > > https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L563 > > > https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L573 > > > https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L583 > > > https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L594 > > > https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L604 > > > > The doc for ValueLayout says: > > > ?"The layout constants in this class make implicit alignment and > byte-ordering assumption: all layout > ?constants in this class are byte-aligned" > > > Which is not true in the code itself. All of the docs for the > constants aren't correct, either. This results in a struct that > *should* have a byte alignment of 8 actually have 1: > > > GroupLayout layout = MemoryLayout.structLayout( > ??????????????? ValueLayout.JAVA_INT, > ??????????????? MemoryLayout.paddingLayout(32), > ??????????????? ValueLayout.JAVA_LONG); > > System.out.println(layout.byteAlignment()); // prints 1! > > > Git blame shows that these issues were introduced a whole 2 months ago > as part of the "beautiful" and "perfect" API changes: > > > https://github.com/openjdk/panama-foreign/blame/c15cb9c11e03c7552d2143273959acac30969db7/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L560 > > > > and no one noticed? There should probably be alignment validation > checks in place to catch this. The fact that constants are declared at > the bottom instead of the top probably didn't help in making this > issue more noticeable. > > > While I'm here, is passing ByteOrder.nativeOrder() to every > constructor needed? > > > On 11/24/21 5:55 AM, Maurizio Cimadamore wrote: >> On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore >> wrote: >> >>> This PR contains the API and implementation changes for JEP-419 [1]. >>> A more detailed description of such changes, to avoid repetitions >>> during the review process, is included as a separate comment. >>> >>> [1] - https://openjdk.java.net/jeps/419 >> This pull request has now been integrated. >> >> Changeset: 96e36071 >> Author:??? Maurizio Cimadamore >> URL: >> https://git.openjdk.java.net/jdk/commit/96e36071b63b624d56739b014b457ffc48147c4f >> Stats:???? 14700 lines in 193 files changed: 6958 ins; 5126 del; 2616 >> mod >> >> 8275063: Implementation of Foreign Function & Memory API (Second >> incubator) >> >> Reviewed-by: erikj, psandoz, jvernee, darcy >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/5907 From maurizio.cimadamore at oracle.com Wed Nov 24 16:53:43 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 24 Nov 2021 16:53:43 +0000 Subject: Integrated: 8275063: Implementation of Foreign Function & Memory API (Second incubator) In-Reply-To: <40cf3777-85fc-5fce-f210-049afdfa6ed5@oracle.com> References: <14b442fb-0612-2664-6e90-e0cbdd7c0203@gmail.com> <40cf3777-85fc-5fce-f210-049afdfa6ed5@oracle.com> Message-ID: <48bffcc8-7575-9872-61f8-4ddaf9df7d9b@oracle.com> (dropping build-dev) Hi, as always the general tone of the email is off in many ways. I'll try to respond to some of the points. On 24/11/2021 16:25, Maurizio Cimadamore wrote: > I think this discussion should go either on core-libs or on > panama-dev. build-dev is not the place for it. I'm addding panama-dev > - and then I'll reply from there. > > Maurizio > > On 24/11/2021 16:15, Ty Young wrote: >> Was this code actually reviewed or even used/tested at all? All >> "Java" ValueLayouts have an 8-bit alignment, even if they are 2-byte, >> 4-byte, or 8-byte in size: Yes. I think it was reviewed and tested. Not just by us but also from the various projects which started to use it. The decision to make all JAVA_XYZ constants byte-aligned was a pragmatic one. All the dereference APIs take a byte offset - but if you want to dereference an `int` in a random, non-aligned memory location, JAVA_INT will not work if JAVA_INT is 4 byte aligned. So we decided to make alignment of these constants to be "loose" which means these layouts work in any dereference scenario. Since these layout constants are not magic in any way, other aligned constants can be defined - you don't have to use these if you don't like them. >> >> >> https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L563 >> >> >> https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L573 >> >> >> https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L583 >> >> >> https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L594 >> >> >> https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L604 >> >> >> >> The doc for ValueLayout says: >> >> >> ?"The layout constants in this class make implicit alignment and >> byte-ordering assumption: all layout >> ?constants in this class are byte-aligned" Yes, this says that basically there's no alignment constraint associated to these constant. Note that withBitAligned(8) and byte-aligned are the same thing. Which means no alignment. >> >> >> Which is not true in the code itself. All of the docs for the >> constants aren't correct, either. This results in a struct that >> *should* have a byte alignment of 8 actually have 1: "Not true in the code itself", "docs aren't correct" - what are you trying to say? What bit of javadoc is incorrect? Or is "incorrect" in the sense that "it doesn't do what I expect it to do" ? >> >> >> GroupLayout layout = MemoryLayout.structLayout( >> ??????????????? ValueLayout.JAVA_INT, >> ??????????????? MemoryLayout.paddingLayout(32), >> ??????????????? ValueLayout.JAVA_LONG); >> >> System.out.println(layout.byteAlignment()); // prints 1! Yes, because JAVA_INT has alignment of 1 (in bytes), JAVA_LONG also has an alignment of 1 (in bytes), padding always has a layout of 1 (in bytes) so overall alignment (in bytes) is 1. This seems to be compatible with what the javadoc says about how the constants are. >> >> >> Git blame shows that these issues were introduced a whole 2 months >> ago as part of the "beautiful" and "perfect" API changes: >> >> >> https://github.com/openjdk/panama-foreign/blame/c15cb9c11e03c7552d2143273959acac30969db7/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java#L560 >> >> >> >> and no one noticed? There should probably be alignment validation >> checks in place to catch this. The fact that constants are declared >> at the bottom instead of the top probably didn't help in making this >> issue more noticeable. I'll skip over the sarcastic quotes (but it doesn't help your cause doing that). What I find worrisome is that this email has been sent _after_ the code has been integrated. If you had genuine concerns over the alignment issues, why waiting _after_ said changes have been integrated? That's why we have a JEP process - Mark sent an email a week ago [1] asking for objections (in addition to the fact that we also have a public PR on github on which you can comment). So, if what you think are "issues" ended up being integrated, as you say 2 months after first being introduced, I think it's a bit cheap to try and blame people working on this project for lack of review and test? As I explained above, this was a deliberate change - which works well with the dereference API we have. So, from our perspective, things have been tested properly - and everything has happened through a very open process. For instance, few weeks ago we learned that Tomcat was also testing the Java 18 bits [1] - and that testing process uncovered some issues in the upcall support, which we have rectified. Maybe we need two sets of constants, aligned and unaligned? Would that address your concern? Maurizio [1] - https://github.com/rmaucher/openssl-panama-foreign >> >> >> While I'm here, is passing ByteOrder.nativeOrder() to every >> constructor needed? >> >> >> On 11/24/21 5:55 AM, Maurizio Cimadamore wrote: >>> On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore >>> wrote: >>> >>>> This PR contains the API and implementation changes for JEP-419 >>>> [1]. A more detailed description of such changes, to avoid >>>> repetitions during the review process, is included as a separate >>>> comment. >>>> >>>> [1] - https://openjdk.java.net/jeps/419 >>> This pull request has now been integrated. >>> >>> Changeset: 96e36071 >>> Author:??? Maurizio Cimadamore >>> URL: >>> https://git.openjdk.java.net/jdk/commit/96e36071b63b624d56739b014b457ffc48147c4f >>> Stats:???? 14700 lines in 193 files changed: 6958 ins; 5126 del; >>> 2616 mod >>> >>> 8275063: Implementation of Foreign Function & Memory API (Second >>> incubator) >>> >>> Reviewed-by: erikj, psandoz, jvernee, darcy >>> >>> ------------- >>> >>> PR: https://git.openjdk.java.net/jdk/pull/5907 From maurizio.cimadamore at oracle.com Wed Nov 24 16:57:50 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 24 Nov 2021 16:57:50 +0000 Subject: Integrated: 8275063: Implementation of Foreign Function & Memory API (Second incubator) In-Reply-To: <48bffcc8-7575-9872-61f8-4ddaf9df7d9b@oracle.com> References: <14b442fb-0612-2664-6e90-e0cbdd7c0203@gmail.com> <40cf3777-85fc-5fce-f210-049afdfa6ed5@oracle.com> <48bffcc8-7575-9872-61f8-4ddaf9df7d9b@oracle.com> Message-ID: On 24/11/2021 16:53, Maurizio Cimadamore wrote: > Mark sent an email a week ago [1] asking for objections Mark email can be found here: https://mail.openjdk.java.net/pipermail/jdk-dev/2021-November/006251.html Maurizio From psandoz at openjdk.java.net Wed Nov 24 17:50:24 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 24 Nov 2021 17:50:24 GMT Subject: [vectorIntrinsics] Integrated: Merge panama-vector:master In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 21:36:16 GMT, Paul Sandoz wrote: > Merge master into `vectorIntrinsics`. > > Conflicts were resolved in `node.hpp` > > @nsjian conflicts were found test/hotspot/gtest/aarch64/asmtest.out.h so I just selected that in `vectorIntrinsics`. Can you please send me updates for that? This pull request has now been integrated. Changeset: a4f3250e Author: Paul Sandoz URL: https://git.openjdk.java.net/panama-vector/commit/a4f3250e54e2b43382f26e1d6fb49c644ff22f9a Stats: 12605 lines in 417 files changed: 9897 ins; 1235 del; 1473 mod Merge panama-vector:master Reviewed-by: njian ------------- PR: https://git.openjdk.java.net/panama-vector/pull/169 From maurizio.cimadamore at oracle.com Wed Nov 24 19:35:50 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 24 Nov 2021 19:35:50 +0000 Subject: Integrated: 8275063: Implementation of Foreign Function & Memory API (Second incubator) In-Reply-To: References: <14b442fb-0612-2664-6e90-e0cbdd7c0203@gmail.com> <40cf3777-85fc-5fce-f210-049afdfa6ed5@oracle.com> <48bffcc8-7575-9872-61f8-4ddaf9df7d9b@oracle.com> Message-ID: <83161f97-062e-517a-5ada-13a0c9c7866a@oracle.com> On 24/11/2021 17:52, Ty Young wrote: > According to Google search results, the ability to do non-aligned > memory access seems to be purely CPU architecture dependent and, even > if allowed(which it is on x86), it comes at a performance penalty. > Again, according to Google search results, an address is only ever > aligned if ADDRESS % TYPE_ALIGNMENT == 0 where the alignment for an > int is the same as its size in bytes(4), which has been my > understanding this whole time and, IIRC, the API would spit out a > misaligned memory access error before these changes if that wasn't the > case. > > > The ability to read/write to misaligned memory is fine, but saying an > INT is 1-byte aligned seems to be factually incorrect. Is setting the > correct alignments and not checking for aligned memory access not > possible? It is possible to set correct alignment and then have unaligned access too. But you need different layouts for aligned and unaligned access. The constant we provide are designed for maximum flexibility (which, as you point out, might sometimes lead to abuse/misuse). In general we have 3 options: 1. expose only aligned constants (like it was in 17) 2. expose only unaligned constant (like it is now) 3. expose both In reality you can always derive an aligned constant from an unaligned one (and viceversa), so all three approaches are fine, really. We switched from (1) to (2) based on some feedback we received (I believe it was from Uwe) where it seemed like unaligned access was more like the norm when working with big slab of data. In general, I believe that, no matter the polarity, somebody is going to be unhappy, unless we do (3). And even if we do (3) somebody could ask: what about BIG_ENDIAN/LITTLE_ENDIAN variants? I really hope this doesn't mean we need to expose 8 * 2 * 2 constants, but I'm open to suggestions as to what set of constants people think it would be useful to expose. This is not a big change. Btw, note that even in 17, JAVA_DOUBLE and JAVA_LONG were not really 8-byte aligned, but were ADDRESS aligned (e.g. in 32-bit VMs longs and doubles can be 4 byte aligned, not 8). > > I only came across this a few days ago after spending hours trying to > debug memory corruption issues in my own projects that I still haven't > figured out by dumping the amount of bytes being allocated, alignment, > etc only to discover that the alignment of everything just prints 1. If you are testing on the panama repo, there is an issue with upcall handling - which is fixed in the patch we integrated 18 (we will merge the fix soon). That issue was causing spurious memory corruption. Maurizio > > > Side note: if misaligned memory access is going to be allowed then > maybe a JVM property should be added to enforce memory alignment even > on architectures that allow it. > > > > On 11/24/21 10:53 AM, Maurizio Cimadamore wrote: >> (dropping build-dev) >> >> Hi, >> as always the general tone of the email is off in many ways. I'll try >> to respond to some of the points. >> >> >> On 24/11/2021 16:25, Maurizio Cimadamore wrote: >>> I think this discussion should go either on core-libs or on >>> panama-dev. build-dev is not the place for it. I'm addding >>> panama-dev - and then I'll reply from there. >>> >>> Maurizio >>> >>> On 24/11/2021 16:15, Ty Young wrote: >>>> Was this code actually reviewed or even used/tested at all? All >>>> "Java" ValueLayouts have an 8-bit alignment, even if they are >>>> 2-byte, 4-byte, or 8-byte in size: >> >> Yes. I think it was reviewed and tested. Not just by us but also from >> the various projects which started to use it. >> >> The decision to make all JAVA_XYZ constants byte-aligned was a >> pragmatic one. All the dereference APIs take a byte offset - but if >> you want to dereference an `int` in a random, non-aligned memory >> location, JAVA_INT will not work if JAVA_INT is 4 byte aligned. >> >> So we decided to make alignment of these constants to be "loose" >> which means these layouts work in any dereference scenario. Since >> these layout constants are not magic in any way, other aligned >> constants can be defined - you don't have to use these if you don't >> like them. >> >>>> >>>> >>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L563__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxP_6RFxQI$ >>>> >>>> >>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L573__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxPLQTWa4Y$ >>>> >>>> >>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L583__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxPUW9AYXs$ >>>> >>>> >>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L594__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxPOVK7jco$ >>>> >>>> >>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L604__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxPas1qRiQ$ >>>> >>>> >>>> >>>> The doc for ValueLayout says: >>>> >>>> >>>> ?"The layout constants in this class make implicit alignment and >>>> byte-ordering assumption: all layout >>>> ?constants in this class are byte-aligned" >> Yes, this says that basically there's no alignment constraint >> associated to these constant. Note that withBitAligned(8) and >> byte-aligned are the same thing. Which means no alignment. >>>> >>>> >>>> Which is not true in the code itself. All of the docs for the >>>> constants aren't correct, either. This results in a struct that >>>> *should* have a byte alignment of 8 actually have 1: >> "Not true in the code itself", "docs aren't correct" - what are you >> trying to say? What bit of javadoc is incorrect? Or is "incorrect" in >> the sense that "it doesn't do what I expect it to do" ? >>>> >>>> >>>> GroupLayout layout = MemoryLayout.structLayout( >>>> ??????????????? ValueLayout.JAVA_INT, >>>> ??????????????? MemoryLayout.paddingLayout(32), >>>> ??????????????? ValueLayout.JAVA_LONG); >>>> >>>> System.out.println(layout.byteAlignment()); // prints 1! >> >> Yes, because JAVA_INT has alignment of 1 (in bytes), JAVA_LONG also >> has an alignment of 1 (in bytes), padding always has a layout of 1 >> (in bytes) so overall alignment (in bytes) is 1. >> >> This seems to be compatible with what the javadoc says about how the >> constants are. >> >> >>>> >>>> >>>> Git blame shows that these issues were introduced a whole 2 months >>>> ago as part of the "beautiful" and "perfect" API changes: >>>> >>>> >>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/blame/c15cb9c11e03c7552d2143273959acac30969db7/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L560__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxPt8Y3Yn4$ >>>> >>>> >>>> >>>> and no one noticed? There should probably be alignment validation >>>> checks in place to catch this. The fact that constants are declared >>>> at the bottom instead of the top probably didn't help in making >>>> this issue more noticeable. >> >> I'll skip over the sarcastic quotes (but it doesn't help your cause >> doing that). >> >> What I find worrisome is that this email has been sent _after_ the >> code has been integrated. If you had genuine concerns over the >> alignment issues, why waiting _after_ said changes have been >> integrated? That's why we have a JEP process - Mark sent an email a >> week ago [1] asking for objections (in addition to the fact that we >> also have a public PR on github on which you can comment). So, if >> what you think are "issues" ended up being integrated, as you say 2 >> months after first being introduced, I think it's a bit cheap to try >> and blame people working on this project for lack of review and test? >> >> As I explained above, this was a deliberate change - which works well >> with the dereference API we have. So, from our perspective, things >> have been tested properly - and everything has happened through a >> very open process. For instance, few weeks ago we learned that Tomcat >> was also testing the Java 18 bits [1] - and that testing process >> uncovered some issues in the upcall support, which we have rectified. >> >> Maybe we need two sets of constants, aligned and unaligned? Would >> that address your concern? >> >> Maurizio >> >> [1] - >> https://urldefense.com/v3/__https://github.com/rmaucher/openssl-panama-foreign__;!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxP8uXm9PU$ >> >> >>>> >>>> >>>> While I'm here, is passing ByteOrder.nativeOrder() to every >>>> constructor needed? >>>> >>>> >>>> On 11/24/21 5:55 AM, Maurizio Cimadamore wrote: >>>>> On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore >>>>> wrote: >>>>> >>>>>> This PR contains the API and implementation changes for JEP-419 >>>>>> [1]. A more detailed description of such changes, to avoid >>>>>> repetitions during the review process, is included as a separate >>>>>> comment. >>>>>> >>>>>> [1] - https://openjdk.java.net/jeps/419 >>>>> This pull request has now been integrated. >>>>> >>>>> Changeset: 96e36071 >>>>> Author:??? Maurizio Cimadamore >>>>> URL: >>>>> https://git.openjdk.java.net/jdk/commit/96e36071b63b624d56739b014b457ffc48147c4f >>>>> Stats:???? 14700 lines in 193 files changed: 6958 ins; 5126 del; >>>>> 2616 mod >>>>> >>>>> 8275063: Implementation of Foreign Function & Memory API (Second >>>>> incubator) >>>>> >>>>> Reviewed-by: erikj, psandoz, jvernee, darcy >>>>> >>>>> ------------- >>>>> >>>>> PR: https://git.openjdk.java.net/jdk/pull/5907 From youngty1997 at gmail.com Wed Nov 24 21:12:09 2021 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 24 Nov 2021 15:12:09 -0600 Subject: Integrated: 8275063: Implementation of Foreign Function & Memory API (Second incubator) In-Reply-To: <83161f97-062e-517a-5ada-13a0c9c7866a@oracle.com> References: <14b442fb-0612-2664-6e90-e0cbdd7c0203@gmail.com> <40cf3777-85fc-5fce-f210-049afdfa6ed5@oracle.com> <48bffcc8-7575-9872-61f8-4ddaf9df7d9b@oracle.com> <83161f97-062e-517a-5ada-13a0c9c7866a@oracle.com> Message-ID: <37956823-1e05-d01a-2453-da21a42bdbc9@gmail.com> On 11/24/21 1:35 PM, Maurizio Cimadamore wrote: > > On 24/11/2021 17:52, Ty Young wrote: >> According to Google search results, the ability to do non-aligned >> memory access seems to be purely CPU architecture dependent and, even >> if allowed(which it is on x86), it comes at a performance penalty. >> Again, according to Google search results, an address is only ever >> aligned if ADDRESS % TYPE_ALIGNMENT == 0 where the alignment for an >> int is the same as its size in bytes(4), which has been my >> understanding this whole time and, IIRC, the API would spit out a >> misaligned memory access error before these changes if that wasn't >> the case. >> >> >> The ability to read/write to misaligned memory is fine, but saying an >> INT is 1-byte aligned seems to be factually incorrect. Is setting the >> correct alignments and not checking for aligned memory access not >> possible? > > It is possible to set correct alignment and then have unaligned access > too. But you need different layouts for aligned and unaligned access. > The constant we provide are designed for maximum flexibility (which, > as you point out, might sometimes lead to abuse/misuse). > > In general we have 3 options: > > 1. expose only aligned constants (like it was in 17) > 2. expose only unaligned constant (like it is now) > 3. expose both > > In reality you can always derive an aligned constant from an unaligned > one (and viceversa), so all three approaches are fine, really. > > We switched from (1) to (2) based on some feedback we received (I > believe it was from Uwe) where it seemed like unaligned access was > more like the norm when working with big slab of data. > > In general, I believe that, no matter the polarity, somebody is going > to be unhappy, unless we do (3). And even if we do (3) somebody could > ask: what about BIG_ENDIAN/LITTLE_ENDIAN variants? > > I really hope this doesn't mean we need to expose 8 * 2 * 2 constants, > but I'm open to suggestions as to what set of constants people think > it would be useful to expose. This is not a big change. > > Btw, note that even in 17, JAVA_DOUBLE and JAVA_LONG were not really > 8-byte aligned, but were ADDRESS aligned (e.g. in 32-bit VMs longs and > doubles can be 4 byte aligned, not 8). > > Hopefully everyone can agree that there is a difference between redefining(violating?) already existing, long established terminology and taking cosmetic liberties with API design. I have no idea what Uwe needs unaligned access for(uses less memory?) but I can't see how the current alignment scheme makes sense. If someone wanted to do something different then they are probably in the special use case situation, not the other way around. What constants someone might be interested in seems kind of dependent on if they are only interested in off-heap memory for use in Java or working with native code. Regardless of what's exposed, how is someone supposed to use a VarHandles when the layout that you use to create a MemorySegment has a mutable meaning? Using a long handle on a MemorySegment created using the ValueLayout of an int just causes an index out of bounds exception, for example. It's not pretty, but for what it's worth, best thing I can think of is to just define types like INT8, INT16, etc. Maybe anything other than the native order should be considered a niche just like overriding bit alignment. >> >> I only came across this a few days ago after spending hours trying to >> debug memory corruption issues in my own projects that I still >> haven't figured out by dumping the amount of bytes being allocated, >> alignment, etc only to discover that the alignment of everything just >> prints 1. > > If you are testing on the panama repo, there is an issue with upcall > handling - which is fixed in the patch we integrated 18 (we will merge > the fix soon). That issue was causing spurious memory corruption. Not sure if I'm explicitly using upcalls myself. I'm trying to use a mapped memory file as an "accounting allocator"(reports memory allocated, number of allocations) which gets my app to launch but then it will randomly start reporting strange values, typically data that comes from struct fields. Either memory corruption, or bytes are being shared between segments. > > Maurizio > >> >> >> Side note: if misaligned memory access is going to be allowed then >> maybe a JVM property should be added to enforce memory alignment even >> on architectures that allow it. >> >> >> >> On 11/24/21 10:53 AM, Maurizio Cimadamore wrote: >>> (dropping build-dev) >>> >>> Hi, >>> as always the general tone of the email is off in many ways. I'll >>> try to respond to some of the points. >>> >>> >>> On 24/11/2021 16:25, Maurizio Cimadamore wrote: >>>> I think this discussion should go either on core-libs or on >>>> panama-dev. build-dev is not the place for it. I'm addding >>>> panama-dev - and then I'll reply from there. >>>> >>>> Maurizio >>>> >>>> On 24/11/2021 16:15, Ty Young wrote: >>>>> Was this code actually reviewed or even used/tested at all? All >>>>> "Java" ValueLayouts have an 8-bit alignment, even if they are >>>>> 2-byte, 4-byte, or 8-byte in size: >>> >>> Yes. I think it was reviewed and tested. Not just by us but also >>> from the various projects which started to use it. >>> >>> The decision to make all JAVA_XYZ constants byte-aligned was a >>> pragmatic one. All the dereference APIs take a byte offset - but if >>> you want to dereference an `int` in a random, non-aligned memory >>> location, JAVA_INT will not work if JAVA_INT is 4 byte aligned. >>> >>> So we decided to make alignment of these constants to be "loose" >>> which means these layouts work in any dereference scenario. Since >>> these layout constants are not magic in any way, other aligned >>> constants can be defined - you don't have to use these if you don't >>> like them. >>> >>>>> >>>>> >>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L563__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxP_6RFxQI$ >>>>> >>>>> >>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L573__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxPLQTWa4Y$ >>>>> >>>>> >>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L583__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxPUW9AYXs$ >>>>> >>>>> >>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L594__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxPOVK7jco$ >>>>> >>>>> >>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/cf7adae6333c7446048ef0364737927337631f63/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L604__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxPas1qRiQ$ >>>>> >>>>> >>>>> >>>>> The doc for ValueLayout says: >>>>> >>>>> >>>>> ?"The layout constants in this class make implicit alignment and >>>>> byte-ordering assumption: all layout >>>>> ?constants in this class are byte-aligned" >>> Yes, this says that basically there's no alignment constraint >>> associated to these constant. Note that withBitAligned(8) and >>> byte-aligned are the same thing. Which means no alignment. >>>>> >>>>> >>>>> Which is not true in the code itself. All of the docs for the >>>>> constants aren't correct, either. This results in a struct that >>>>> *should* have a byte alignment of 8 actually have 1: >>> "Not true in the code itself", "docs aren't correct" - what are you >>> trying to say? What bit of javadoc is incorrect? Or is "incorrect" >>> in the sense that "it doesn't do what I expect it to do" ? >>>>> >>>>> >>>>> GroupLayout layout = MemoryLayout.structLayout( >>>>> ??????????????? ValueLayout.JAVA_INT, >>>>> ??????????????? MemoryLayout.paddingLayout(32), >>>>> ??????????????? ValueLayout.JAVA_LONG); >>>>> >>>>> System.out.println(layout.byteAlignment()); // prints 1! >>> >>> Yes, because JAVA_INT has alignment of 1 (in bytes), JAVA_LONG also >>> has an alignment of 1 (in bytes), padding always has a layout of 1 >>> (in bytes) so overall alignment (in bytes) is 1. >>> >>> This seems to be compatible with what the javadoc says about how the >>> constants are. >>> >>> >>>>> >>>>> >>>>> Git blame shows that these issues were introduced a whole 2 months >>>>> ago as part of the "beautiful" and "perfect" API changes: >>>>> >>>>> >>>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/blame/c15cb9c11e03c7552d2143273959acac30969db7/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java*L560__;Iw!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxPt8Y3Yn4$ >>>>> >>>>> >>>>> >>>>> and no one noticed? There should probably be alignment validation >>>>> checks in place to catch this. The fact that constants are >>>>> declared at the bottom instead of the top probably didn't help in >>>>> making this issue more noticeable. >>> >>> I'll skip over the sarcastic quotes (but it doesn't help your cause >>> doing that). >>> >>> What I find worrisome is that this email has been sent _after_ the >>> code has been integrated. If you had genuine concerns over the >>> alignment issues, why waiting _after_ said changes have been >>> integrated? That's why we have a JEP process - Mark sent an email a >>> week ago [1] asking for objections (in addition to the fact that we >>> also have a public PR on github on which you can comment). So, if >>> what you think are "issues" ended up being integrated, as you say 2 >>> months after first being introduced, I think it's a bit cheap to try >>> and blame people working on this project for lack of review and test? >>> >>> As I explained above, this was a deliberate change - which works >>> well with the dereference API we have. So, from our perspective, >>> things have been tested properly - and everything has happened >>> through a very open process. For instance, few weeks ago we learned >>> that Tomcat was also testing the Java 18 bits [1] - and that testing >>> process uncovered some issues in the upcall support, which we have >>> rectified. >>> >>> Maybe we need two sets of constants, aligned and unaligned? Would >>> that address your concern? >>> >>> Maurizio >>> >>> [1] - >>> https://urldefense.com/v3/__https://github.com/rmaucher/openssl-panama-foreign__;!!ACWV5N9M2RV99hQ!a1C1m4R7w_at55VXOIwKBSatP_3VH9jhl5Z6O0Ct48LgUyGzKL-WE0j4fOXoaUxP8uXm9PU$ >>> >>> >>>>> >>>>> >>>>> While I'm here, is passing ByteOrder.nativeOrder() to every >>>>> constructor needed? >>>>> >>>>> >>>>> On 11/24/21 5:55 AM, Maurizio Cimadamore wrote: >>>>>> On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore >>>>>> wrote: >>>>>> >>>>>>> This PR contains the API and implementation changes for JEP-419 >>>>>>> [1]. A more detailed description of such changes, to avoid >>>>>>> repetitions during the review process, is included as a separate >>>>>>> comment. >>>>>>> >>>>>>> [1] - https://openjdk.java.net/jeps/419 >>>>>> This pull request has now been integrated. >>>>>> >>>>>> Changeset: 96e36071 >>>>>> Author:??? Maurizio Cimadamore >>>>>> URL: >>>>>> https://git.openjdk.java.net/jdk/commit/96e36071b63b624d56739b014b457ffc48147c4f >>>>>> Stats:???? 14700 lines in 193 files changed: 6958 ins; 5126 del; >>>>>> 2616 mod >>>>>> >>>>>> 8275063: Implementation of Foreign Function & Memory API (Second >>>>>> incubator) >>>>>> >>>>>> Reviewed-by: erikj, psandoz, jvernee, darcy >>>>>> >>>>>> ------------- >>>>>> >>>>>> PR: https://git.openjdk.java.net/jdk/pull/5907 From maurizio.cimadamore at oracle.com Wed Nov 24 21:21:42 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 24 Nov 2021 21:21:42 +0000 Subject: Integrated: 8275063: Implementation of Foreign Function & Memory API (Second incubator) In-Reply-To: <37956823-1e05-d01a-2453-da21a42bdbc9@gmail.com> References: <14b442fb-0612-2664-6e90-e0cbdd7c0203@gmail.com> <40cf3777-85fc-5fce-f210-049afdfa6ed5@oracle.com> <48bffcc8-7575-9872-61f8-4ddaf9df7d9b@oracle.com> <83161f97-062e-517a-5ada-13a0c9c7866a@oracle.com> <37956823-1e05-d01a-2453-da21a42bdbc9@gmail.com> Message-ID: <865eda12-653e-dc75-406c-6b2ed538ec67@oracle.com> On 24/11/2021 21:12, Ty Young wrote: > Regardless of what's exposed, how is someone supposed to use a > VarHandles when the layout that you use to create a MemorySegment has > a mutable meaning? Using a long handle on a MemorySegment created > using the ValueLayout of an int just causes an index out of bounds > exception, for example. Not sure I follow here - what do you mean by "mutable" meaning? Sure, if you create a segment with a layout that is 4 bytes and you try to get 8 bytes out of it there's gonna be an issue. But I don't understand what you mean by mutable. Clearly you can't mean mutable as in "this thing can go from 4 byte of size to 8 byte". So you probably refer to the fact that a native long on windows is 4 bytes, where on other 64-bit platforms is 8 bytes? That would be true of course (but now we're not speaking about JAVA_XYZ layouts anymore, are we?). To deal with C types in the correct way, jextract emits layouts for all the basic primitive types and typedefs. So, since you're not using jextract you would have to do something similar; or even used sized constant as you mentioned, if you want to achieve more portability. Maurizio From jbhateja at openjdk.java.net Thu Nov 25 06:12:21 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 25 Nov 2021 06:12:21 GMT Subject: [vectorIntrinsics+mask] Withdrawn: 8273322: Enhance macro logic optimization for masked logic operations. In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 16:06:14 GMT, Jatin Bhateja wrote: > Patch extends existing macrologic inferencing algorithm to handle masked logic operations. > > Existing algorithm: > 1) Identify logic cone roots. > 2) Packs parent and logic child nodes into a MacroLogic node in bottom up traversal if input constraint are met. > i.e. maximum number of inputs which a macro logic node can have. > 3) Perform symbolic evaluation of logic expression tree by assigning value corresponding to a truth table column > to each input. > 4) Inputs along with encoded function together represents a macro logic node which mimics a truth table. > > Modification: > Extended the packing algorithm to operate on both predicated or non-predicated logic nodes. Following > rules define the criteria under which nodes gets packed into a macro logic node:- > 1) Parent and both child nodes are all unmasked or masked with same predicates. > 2) Masked parent can be packed with left child if it is predicated and both have same prediates. > 3) Masked parent can be packed with right child if its un-predicated or has matching predication condition. > 4) An unmasked parent can be packed with an unmasked child. > > New jtreg test case added with the patch exhaustively covers all the different combinations of predications of parent and > child nodes. > > Following are the performance number for JMH benchmark included with the patch. > > Machine Configuration: Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz (Cascadelake Server 28C 2S) > > > Benchmark | SPECIES | VECLEN | Baseline Score (ops/ms) | With Opt Score (ops/ms) | Gain Ratio > -- | -- | -- | -- | -- | -- > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 256 | 594.425 | 616.74 | 1.03754048 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 512 | 596.433 | 616.405 | 1.033485739 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 1024 | 586.716 | 618.718 | 1.054544277 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 2048 | 594.68 | 618.235 | 1.039609538 > MaskedLogicOpts.bitwiseBlendOperationInt | 128 | 4096 | 595.357 | 617.803 | 1.037701749 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 256 | 503.396 | 602.252 | 1.196378199 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 512 | 529.454 | 572.485 | 1.081274294 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 1024 | 560.688 | 587.143 | 1.047183104 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 2048 | 539.919 | 586.473 | 1.086224045 > MaskedLogicOpts.bitwiseBlendOperationInt | 256 | 4096 | 542.102 | 586.694 | 1.082257583 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 256 | 401.552 | 474.281 | 1.181119755 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 512 | 371.352 | 520.497 | 1.401627028 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 1024 | 403.174 | 514.51 | 1.27614876 > MaskedLogicOpts.bitwiseBlendOperationInt | 512 | 2048 | 386.124 | 511.22 | 1.323978825 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 256 | 316.054 | 654.797 | 2.071788365 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 512 | 312.912 | 600.227 | 1.918197448 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 1024 | 305.86 | 614.129 | 2.007876152 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 2048 | 306.589 | 617.645 | 2.014569994 > MaskedLogicOpts.maskedLogicOperationsInt | 512 | 4096 | 314.896 | 619.618 | 1.96769092 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 256 | 12.32 | 17.629 | 1.430925325 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 512 | 12.296 | 17.632 | 1.433962264 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 1024 | 12.027 | 17.663 | 1.468612289 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 2048 | 12.33 | 17.601 | 1.427493917 > MaskedLogicOpts.maskedLogicOperationsLong | 128 | 4096 | 12.329 | 17.65 | 1.43158407 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 256 | 413.078 | 1184.616 | 2.867777998 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 512 | 431.578 | 1069.109 | 2.477209218 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 1024 | 430.099 | 1089.835 | 2.53391661 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 2048 | 420.341 | 1204.934 | 2.8665631 > MaskedLogicOpts.maskedLogicOperationsLong | 256 | 4096 | 431.571 | 1069.704 | 2.478628082 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 256 | 311.43 | 599.982 | 1.926538869 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 512 | 305.459 | 620.418 | 2.031100737 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 1024 | 304.885 | 611.37 | 2.00524788 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 2048 | 305.198 | 619.347 | 2.029328501 > MaskedLogicOpts.maskedLogicOperationsLong | 512 | 4096 | 305.317 | 615.882 | 2.017188692 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 256 | 781.922 | 856.605 | 1.095512084 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 512 | 752.428 | 856.559 | 1.138393308 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 1024 | 764.4 | 837.68 | 1.095866039 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 2048 | 780.311 | 857.797 | 1.099301432 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 128 | 4096 | 780.489 | 837.536 | 1.073091357 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 256 | 703.881 | 820.539 | 1.165735401 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 512 | 698.958 | 822.174 | 1.17628527 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 1024 | 715.533 | 806.71 | 1.12742529 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 2048 | 678.087 | 797.53 | 1.176147014 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 256 | 4096 | 714.427 | 824.008 | 1.153383061 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 256 | 400.801 | 547.414 | 1.365799986 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 512 | 453.713 | 602.492 | 1.327914342 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 1024 | 467.685 | 612.172 | 1.308940847 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 2048 | 467.286 | 612.659 | 1.311100696 > MaskedLogicOpts.partiallyMaskedLogicOperationsInt | 512 | 4096 | 465.71 | 671.911 | 1.442766958 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 256 | 18.25 | 24.524 | 1.343780822 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 512 | 18.634 | 24.408 | 1.30986369 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 1024 | 18.566 | 24.839 | 1.337875687 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 2048 | 18.568 | 24.65 | 1.327552779 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 128 | 4096 | 18.685 | 24.448 | 1.308429221 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 256 | 658.381 | 788.086 | 1.197005989 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 512 | 679.09 | 780.808 | 1.149785743 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 1024 | 675.793 | 783.304 | 1.159088656 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 2048 | 679.09 | 823.756 | 1.213029201 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 256 | 4096 | 677.724 | 782.655 | 1.154828514 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 256 | 456.231 | 620.547 | 1.360159656 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 512 | 468.07 | 604.75 | 1.292007606 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 1024 | 467.188 | 605.256 | 1.295529851 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 2048 | 468.52 | 605.854 | 1.293123026 > MaskedLogicOpts.partiallyMaskedLogicOperationsLong | 512 | 4096 | 467.954 | 605.996 | 1.294990533 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/125 From duke at openjdk.java.net Thu Nov 25 07:56:27 2021 From: duke at openjdk.java.net (Mai =?UTF-8?B?xJDhurduZw==?= =?UTF-8?B?IA==?= =?UTF-8?B?UXXDom4=?= Anh) Date: Thu, 25 Nov 2021 07:56:27 GMT Subject: [vectorIntrinsics] Withdrawn: Improve mask reduction operations on AVX In-Reply-To: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> References: <2hqYAzREaL7JPqcoUOFZuc4ilyt1UzByeMehz8w9760=.684159f7-f481-4f3d-bcb3-04e9ef9ffeb7@github.com> Message-ID: On Tue, 2 Nov 2021 10:58:19 GMT, Mai ??ng Qu?n Anh wrote: > Hi, > This patch improves the logic of vector mask reduction operations on AVX, especially int, float, long, double, by using vmovmskpd and vmovmskps instructions. I also do a little refactoring to reduce duplication in toLong. The patch temporarily disables these operations on Neon, though. > Thank you very much. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/158 From jvernee at openjdk.java.net Thu Nov 25 14:50:44 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 25 Nov 2021 14:50:44 GMT Subject: [foreign-memaccess+abi] RFR: 8277657: OptimizedEntryBlob should extend RuntimeBlob directly Message-ID: <0tDqEfdSUG-U3vCYLA-R0YWAj9pZlBOqXDBZh_RxRAc=.bd2a4a30-ca3b-4841-a375-8dfbf58a6e43@github.com> This small refactoring makes OptimizedEntryBlob extend RuntimeBlob instead of BufferBlob. The motivation for doing this is that we don't want to inherit behavior from BufferBlob by accident which is not appropriate for OptimizedEntryBlob, which has happened in the past. This patch also reverts an earlier fix by Nick which made BufferBlob sub classes pass their header size through the BufferBlob constructor to RuntimeBlob's constructor, since this is no longer needed with this patch. ------------- Commit messages: - Don't use no_frame_size, since it's a C1 constant - Move operator new - OptimizedEntryBlob implements RuntimeBlob directly Changes: https://git.openjdk.java.net/panama-foreign/pull/617/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=617&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277657 Stats: 87 lines in 3 files changed: 54 ins; 11 del; 22 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/617.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/617/head:pull/617 PR: https://git.openjdk.java.net/panama-foreign/pull/617 From jvernee at openjdk.java.net Thu Nov 25 14:50:47 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 25 Nov 2021 14:50:47 GMT Subject: [foreign-memaccess+abi] RFR: 8277657: OptimizedEntryBlob should extend RuntimeBlob directly In-Reply-To: <0tDqEfdSUG-U3vCYLA-R0YWAj9pZlBOqXDBZh_RxRAc=.bd2a4a30-ca3b-4841-a375-8dfbf58a6e43@github.com> References: <0tDqEfdSUG-U3vCYLA-R0YWAj9pZlBOqXDBZh_RxRAc=.bd2a4a30-ca3b-4841-a375-8dfbf58a6e43@github.com> Message-ID: On Thu, 25 Nov 2021 14:42:25 GMT, Jorn Vernee wrote: > This small refactoring makes OptimizedEntryBlob extend RuntimeBlob instead of BufferBlob. > > The motivation for doing this is that we don't want to inherit behavior from BufferBlob by accident which is not appropriate for OptimizedEntryBlob, which has happened in the past. > > This patch also reverts an earlier fix by Nick which made BufferBlob sub classes pass their header size through the BufferBlob constructor to RuntimeBlob's constructor, since this is no longer needed with this patch. src/hotspot/share/code/codeBlob.cpp line 172: > 170: // Track memory usage statistic after releasing CodeCache_lock > 171: MemoryService::track_code_cache_memory_usage(); > 172: } Note that this is just the implementation of BufferBlob::free. Now both BufferBlob::free and OptimizedEntryBlob::free delegate to this function. src/hotspot/share/code/codeBlob.cpp line 776: > 774: > 775: void OptimizedEntryBlob::preserve_callee_argument_oops(frame fr, const RegisterMap* reg_map, OopClosure* f) { > 776: // do nothing for now Will implement this in a followup, for review simplicity. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/617 From maurizio.cimadamore at oracle.com Thu Nov 25 15:52:29 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 25 Nov 2021 15:52:29 +0000 Subject: Java value layout constants Message-ID: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> Hi, This is a followup of the disccussion that started in [1]. In the new changes slated for Java 18, the set of Java value layout constants are all byte-aligned (e.g. alignment constraints are not set). The motivation for this is mostly historical (but there's also a performance twist, see below): the dereference primitives in MemoryAccess used to setup var handles based on non-aligned layouts. So, to preserve compatibility with what we had before, we opted to "relax" alignment constraints on the JAVA_XYZ layout constants in ValueLayout. During the development of the new dereference API, some issues arised around alignment checks and memory copy [2]; which also contributed to consolidate the feeling that Java layout constants should be unaligned. Now, while it's always possible, for clients, to go back to the desired alignment constraints (e.g. by defining custom layout constants), from the discussion it emerged that it can be somewhat confusing/surprising having a layout constant called JAVA_INT, whose alignment is not the VM alignment for a Java int value. For this reason, I'd like to propose a small tweak, which would essentially revert alignment constraints for Java layout constants to what they were in 17. In other words, let's keep the "good" JAVA_XYZ names for the _true_ Java layouts (including alignment as seen by VM). If clients want to create unaligned constants they can do so, as they can also create big-endian constants where needed. In the majority of cases, since access will be aligned (for performance reasons), this will not really change much for clients. But some of those clients that need to pack data structures more (Lucene?) will need to define their own packed/unaligned layout constants. Does that seem like an acceptable compromise? A patch for these changes is available here: https://github.com/mcimadamore/jdk/tree/value_layout_align While testing it, I was reminded (once more) that access with alignment constraints is currently slower than access w/o alignment constraints - which has to do with C2 not hoisting alignment checks in cases like this: ((segmentBaseAddress + accessedOffset) & alignmentMask) == 0 Here, segmentBaseAddress is a loop invariant, and the accessedOffset depends on the loop variable. So, it is in principle possible for the VM to hoist the check for baseAddress and to eliminate the alignment check for the offset (which would come from BCE analysis). But this is not how things work today. The patch works around this, by using different var handles for when the accessed offset is provably aligned (e.g. when using the getAtIndex/setAtIndex APIs). Even with those workarounds, calling getAtIndex/setAtIndex on a MemoryAddress is still slower than on a MemorySegment, because of the way in which we try to workaround the long loop optimization problem. Luckily a fix for that problem [3] has been integrated in JDK 18, which means we will remove these implementation workaround, which will help making performance more stable across the board. If the changes in this patch seem good, I'm happy to try and integrate this into 18. Cheers Maurizio [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015805.html [2] - https://github.com/openjdk/panama-foreign/pull/555#issuecomment-865115787 [3] - https://github.com/openjdk/jdk/pull/2045 From mcimadamore at openjdk.java.net Thu Nov 25 17:47:20 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 25 Nov 2021 17:47:20 GMT Subject: [foreign-memaccess+abi] RFR: 8277657: OptimizedEntryBlob should extend RuntimeBlob directly In-Reply-To: <0tDqEfdSUG-U3vCYLA-R0YWAj9pZlBOqXDBZh_RxRAc=.bd2a4a30-ca3b-4841-a375-8dfbf58a6e43@github.com> References: <0tDqEfdSUG-U3vCYLA-R0YWAj9pZlBOqXDBZh_RxRAc=.bd2a4a30-ca3b-4841-a375-8dfbf58a6e43@github.com> Message-ID: On Thu, 25 Nov 2021 14:42:25 GMT, Jorn Vernee wrote: > This small refactoring makes OptimizedEntryBlob extend RuntimeBlob instead of BufferBlob. > > The motivation for doing this is that we don't want to inherit behavior from BufferBlob by accident which is not appropriate for OptimizedEntryBlob, which has happened in the past. > > This patch also reverts an earlier fix by Nick which made BufferBlob sub classes pass their header size through the BufferBlob constructor to RuntimeBlob's constructor, since this is no longer needed with this patch. Generally looks good - one bit of refactoring looks suspicious. src/hotspot/share/code/codeBlob.cpp line 297: > 295: > 296: AdapterBlob::AdapterBlob(int size, CodeBuffer* cb) : > 297: BufferBlob("I2C/C2I adapters", size, cb) { the header size here used to be sizeof(AdapterBlob), but now is sizeof(BufferBlob) - is that an issue? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/617 From mcimadamore at openjdk.java.net Thu Nov 25 18:01:23 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 25 Nov 2021 18:01:23 GMT Subject: [foreign-memaccess+abi] RFR: 8277657: OptimizedEntryBlob should extend RuntimeBlob directly In-Reply-To: <0tDqEfdSUG-U3vCYLA-R0YWAj9pZlBOqXDBZh_RxRAc=.bd2a4a30-ca3b-4841-a375-8dfbf58a6e43@github.com> References: <0tDqEfdSUG-U3vCYLA-R0YWAj9pZlBOqXDBZh_RxRAc=.bd2a4a30-ca3b-4841-a375-8dfbf58a6e43@github.com> Message-ID: On Thu, 25 Nov 2021 14:42:25 GMT, Jorn Vernee wrote: > This small refactoring makes OptimizedEntryBlob extend RuntimeBlob instead of BufferBlob. > > The motivation for doing this is that we don't want to inherit behavior from BufferBlob by accident which is not appropriate for OptimizedEntryBlob, which has happened in the past. > > This patch also reverts an earlier fix by Nick which made BufferBlob sub classes pass their header size through the BufferBlob constructor to RuntimeBlob's constructor, since this is no longer needed with this patch. Marked as reviewed by mcimadamore (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/617 From jvernee at openjdk.java.net Thu Nov 25 18:01:24 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 25 Nov 2021 18:01:24 GMT Subject: [foreign-memaccess+abi] RFR: 8277657: OptimizedEntryBlob should extend RuntimeBlob directly In-Reply-To: References: <0tDqEfdSUG-U3vCYLA-R0YWAj9pZlBOqXDBZh_RxRAc=.bd2a4a30-ca3b-4841-a375-8dfbf58a6e43@github.com> Message-ID: On Thu, 25 Nov 2021 17:43:36 GMT, Maurizio Cimadamore wrote: >> This small refactoring makes OptimizedEntryBlob extend RuntimeBlob instead of BufferBlob. >> >> The motivation for doing this is that we don't want to inherit behavior from BufferBlob by accident which is not appropriate for OptimizedEntryBlob, which has happened in the past. >> >> This patch also reverts an earlier fix by Nick which made BufferBlob sub classes pass their header size through the BufferBlob constructor to RuntimeBlob's constructor, since this is no longer needed with this patch. > > src/hotspot/share/code/codeBlob.cpp line 297: > >> 295: >> 296: AdapterBlob::AdapterBlob(int size, CodeBuffer* cb) : >> 297: BufferBlob("I2C/C2I adapters", size, cb) { > > the header size here used to be sizeof(AdapterBlob), but now is sizeof(BufferBlob) - is that an issue? This is not an issue since they are the same. Arguably the header size should be passed as `sizeof(AdapterBlob)` for clarity, but I've reverted this to how it is done in the mainline jdk to avoid unnecessary churn for the next JEP: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeBlob.cpp#L292-L295 I think if it's worth fixing, it should be fixed in the mainline. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/617 From duke at openjdk.java.net Thu Nov 25 18:41:17 2021 From: duke at openjdk.java.net (duke) Date: Thu, 25 Nov 2021 18:41:17 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: Changeset: 77dbcdb8 Author: Jorn Vernee Date: 2021-11-25 18:39:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77dbcdb8991711f3a660bad16b5355a801779a81 8277657: OptimizedEntryBlob should extend RuntimeBlob directly Reviewed-by: mcimadamore ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/prims/whitebox.cpp Changeset: 84646836 Author: duke Date: 2021-11-25 18:40:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/84646836d144a210b5afb437500041aeb3942458 Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Thu Nov 25 18:42:28 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 25 Nov 2021 18:42:28 GMT Subject: [foreign-memaccess+abi] Integrated: 8277657: OptimizedEntryBlob should extend RuntimeBlob directly In-Reply-To: <0tDqEfdSUG-U3vCYLA-R0YWAj9pZlBOqXDBZh_RxRAc=.bd2a4a30-ca3b-4841-a375-8dfbf58a6e43@github.com> References: <0tDqEfdSUG-U3vCYLA-R0YWAj9pZlBOqXDBZh_RxRAc=.bd2a4a30-ca3b-4841-a375-8dfbf58a6e43@github.com> Message-ID: <81fZRV3Rz3Y-vWza3JLSnMJntLBN4gzmyi7Seq16p6Y=.502f3ac4-42f9-496c-b84b-0f724bcdbf2d@github.com> On Thu, 25 Nov 2021 14:42:25 GMT, Jorn Vernee wrote: > This small refactoring makes OptimizedEntryBlob extend RuntimeBlob instead of BufferBlob. > > The motivation for doing this is that we don't want to inherit behavior from BufferBlob by accident which is not appropriate for OptimizedEntryBlob, which has happened in the past. > > This patch also reverts an earlier fix by Nick which made BufferBlob sub classes pass their header size through the BufferBlob constructor to RuntimeBlob's constructor, since this is no longer needed with this patch. This pull request has now been integrated. Changeset: 77dbcdb8 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/77dbcdb8991711f3a660bad16b5355a801779a81 Stats: 87 lines in 3 files changed: 54 ins; 11 del; 22 mod 8277657: OptimizedEntryBlob should extend RuntimeBlob directly Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/617 From duke at openjdk.java.net Fri Nov 26 11:06:27 2021 From: duke at openjdk.java.net (duke) Date: Fri, 26 Nov 2021 11:06:27 GMT Subject: git: openjdk/panama-foreign: master: 84 new changesets Message-ID: <1107b1d3-086f-4cc6-94bf-2d68e0db2cfb@openjdk.org> Changeset: 03debf27 Author: Daniel Fuchs Date: 2021-11-19 13:18:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/03debf277537135974d3f55e3a5c7cf6842ee5e0 8276774: Cookie stored in CookieHandler not sent if user headers contain cookie Reviewed-by: michaelm ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java ! src/java.net.http/share/classes/jdk/internal/net/http/Stream.java ! test/jdk/java/net/httpclient/CookieHeaderTest.java = test/jdk/java/net/httpclient/UserCookieTest.java Changeset: b1a1bf4e Author: Claes Redestad Date: 2021-11-19 13:25:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b1a1bf4e305d6675f8f751aa8fef7013d99466f1 8277427: Update jib-profiles.js to use JMH 1.33 devkit Reviewed-by: shade, erikj ! make/conf/jib-profiles.js Changeset: a0227965 Author: Magnus Ihse Bursie Committer: Magnus Ihse Bursie Date: 2021-11-19 13:55:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a0227965bb8d1d49718794d67f8a4cfeebc9bec2 8275745: Reproducible copyright headers Reviewed-by: ihse, erikj ! make/autoconf/basic_tools.m4 ! make/autoconf/jdk-options.m4 ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/jdk/src/classes/build/tools/cldrconverter/CopyrightHeaders.java ! make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java ! make/modules/java.base/Gensrc.gmk ! make/modules/jdk.localedata/Gensrc.gmk Changeset: 936f7ff4 Author: Andy Herrick Date: 2021-11-19 14:23:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/936f7ff49ed86adb74bb1ff10d93cb3d7f7d70a0 8276150: Quarantined jpackage apps are labeled as "damaged" Reviewed-by: almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java Changeset: 03f8c0fb Author: Sean Mullan Date: 2021-11-19 14:36:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/03f8c0fb9363dc1bb07bed1ae0359c029caa0130 8275887: jarsigner prints invalid digest/signature algorithm warnings if keysize is weak/disabled Reviewed-by: weijun ! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java ! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java ! src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java Changeset: 976c2bb0 Author: Stefan Karlsson Date: 2021-11-19 15:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/976c2bb05611cdc7b11b0918aaf50ff693507aae 8277212: GC accidentally cleans valid megamorphic vtable inline caches Reviewed-by: eosterlund, pliden, coleenp, thartmann ! src/hotspot/share/code/compiledMethod.cpp Changeset: 09e8c8c6 Author: Coleen Phillimore Date: 2021-11-19 17:48:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/09e8c8c64abf4178a042c79b92d7e08e54467331 8277342: vmTestbase/nsk/stress/strace/strace004.java fails with SIGSEGV in InstanceKlass::jni_id_for Reviewed-by: dholmes, hseigel ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 66775543 Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:48:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6677554374ade32c9f2ddaaa093064de8aebd831 8274949: Use String.contains() instead of String.indexOf() in java.base Reviewed-by: weijun, dfuchs, vtewari, lancea ! src/java.base/share/classes/java/net/HttpCookie.java ! src/java.base/share/classes/java/net/HttpURLConnection.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/sun/net/www/http/HttpCapture.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java ! src/java.base/share/classes/sun/security/rsa/RSAUtil.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/Debug.java ! src/java.base/share/classes/sun/security/util/SignatureUtil.java ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java ! src/java.base/share/classes/sun/util/locale/LocaleMatcher.java ! src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: 36b59f38 Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:49:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36b59f3814fdaa44c9c04a0e8d63d0ba56929326 8274333: Redundant null comparison after Pattern.split Reviewed-by: mullan, weijun, rriggs, iris ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java Changeset: f609b8fd Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:50:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f609b8fd74c55f3149d8e5a6a9a9bc3598c0b961 8274946: Cleanup unnecessary calls to Throwable.initCause() in java.rmi Reviewed-by: iris, rriggs ! src/java.rmi/share/classes/java/rmi/server/RMIClassLoader.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java ! src/java.rmi/share/classes/javax/rmi/ssl/SslRMIClientSocketFactory.java ! src/java.rmi/share/classes/javax/rmi/ssl/SslRMIServerSocketFactory.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java Changeset: e47cc81b Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:51:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e47cc81b095381266104e9137495e91fb4c225a4 8275386: Change nested classes in jdk.jlink to static nested classes Reviewed-by: alanb, rriggs, iris ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolManager.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java Changeset: a3406a1d Author: Thomas Stuefe Date: 2021-11-19 19:49:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a3406a1d8ab4228b06b4f2978f87275093c39468 8277092: TestMetaspaceAllocationMT2.java#ndebug-default fails with "RuntimeException: Committed seems high: NNNN expected at most MMMM" Reviewed-by: coleenp ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestContext.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestManyArenasManyThreads.java Changeset: 2d4af225 Author: Yasumasa Suenaga Date: 2021-11-19 20:24:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d4af2255feb2eaeca533424f8cba3ec0945d757 8277370: configure script cannot distinguish WSL version Reviewed-by: erikj ! make/autoconf/basic_windows.m4 Changeset: 2ab43ec2 Author: Pavel Rappo Date: 2021-11-19 20:51:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ab43ec2428edaebfe9a7fb0e716ff7141a28de0 8273544: Increase test coverage for snippets Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attributes.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Replace.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Style.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/SnippetTester.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetPathOption.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: c79a485f Author: Daniel D. Daugherty Date: 2021-11-19 22:37:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c79a485f1c3f9c0c3a79b8847fdcd50a141cd529 8277494: [BACKOUT] JDK-8276150 Quarantined jpackage apps are labeled as "damaged" Reviewed-by: asemenyuk, tschatzl ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java Changeset: 1d7cef33 Author: Derek White Date: 2021-11-20 00:48:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d7cef33c5ff24695463a03c58c7ca350ec190fc 8276662: Scalability bottleneck in SymbolTable::lookup_common() Reviewed-by: redestad, dholmes, iklam, shade ! src/hotspot/share/classfile/symbolTable.cpp Changeset: 1c215f33 Author: Vishal Chand Committer: Thomas Schatzl Date: 2021-11-20 10:03:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c215f33698ba2aef4fb230475a9bd33ed3005f9 8272773: Configurable card table card size Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1Arguments.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/objectStartArray.cpp ! src/hotspot/share/gc/parallel/objectStartArray.hpp ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.hpp ! src/hotspot/share/gc/shared/cardTable.cpp ! src/hotspot/share/gc/shared/cardTable.hpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/genArguments.cpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.hpp Changeset: 0a9e76c4 Author: Jie Fu Date: 2021-11-20 10:12:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0a9e76c4f9d966015c19e87e3eb59ceb7489459f 8277485: Zero: Fix _fast_{i,f}access_0 bytecodes handling Reviewed-by: sgehwolf, shade ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 4ff43010 Author: Joe Darcy Date: 2021-11-21 20:42:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ff43010bb3f92bd58f66be52a086b3d078b0cbb 8224922: Access JavaFileObject from Element(s) Co-authored-by: Jan Lahoda Reviewed-by: jjg ! src/java.compiler/share/classes/javax/annotation/processing/Filer.java ! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java ! src/java.compiler/share/classes/javax/lang/model/element/package-info.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java + test/langtools/tools/javac/processing/model/element/TestFileObjectOf.java ! test/langtools/tools/javac/tree/NoPrivateTypesExported.java Changeset: ca31ed53 Author: TatWai Chong Date: 2021-11-22 02:31:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ca31ed5335f6fa7229c94ba20d9d6031b930d69a 8275448: [REDO] AArch64: Implement string_compare intrinsic in SVE Reviewed-by: ngasson, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/register_definitions_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp + test/micro/org/openjdk/bench/java/lang/StringCompareToDifferentLength.java Changeset: 3f847fe8 Author: Aleksey Shipilev Date: 2021-11-22 09:09:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f847fe89a088d6921107ca887a7a1bace871bd6 8277385: Zero: Enable CompactStrings support Reviewed-by: redestad, adinn ! src/hotspot/cpu/zero/globals_zero.hpp Changeset: 8051041e Author: Albert Mingkun Yang Date: 2021-11-22 09:59:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8051041eb2b3d70d4cc62b6f2726279d51e44733 8277534: Remove unused ReferenceProcessor::has_discovered_references Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 32839ba0 Author: Serguei Spitsyn Date: 2021-11-22 10:47:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32839ba012f0a0a66e249cd8d12b94499d82ec0a 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" Reviewed-by: mdoerr, lmesnik, dcubed ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: d427c79d Author: Hamlin Li Date: 2021-11-22 11:27:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d427c79d3bd6c80b67c10d15a461f13ae7e0f84b 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp Changeset: 6b4fbaed Author: Jim Laskey Date: 2021-11-22 16:17:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6b4fbaedbb782c5f028735ac1d92838895589192 8273792: JumpableGenerator.rngs() documentation refers to wrong method Co-authored-by: Guy Steele Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/RandomGenerator.java Changeset: 8683de5e Author: Jim Laskey Date: 2021-11-22 16:19:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8683de5eda2d1a04f187073f969140245908f324 8274685: Documentation suggests there are ArbitrarilyJumpableGenerator when none Co-authored-by: Guy Steele Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/package-info.java Changeset: e5298655 Author: Jatin Bhateja Date: 2021-11-22 16:38:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e529865531d0eb5a2119a1d220b195d088794226 8277239: SIGSEGV in vrshift_reg_maskedNode::emit Reviewed-by: sviswanathan, dlong ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp Changeset: 22f12ac4 Author: Joe Darcy Date: 2021-11-22 16:59:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/22f12ac429fbbf134d182d9bf2a16a3d43bc71e1 8277522: Make formatting of null consistent in Elements Reviewed-by: jlahoda ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 33e2a518 Author: Leonid Mesnik Date: 2021-11-22 17:11:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/33e2a518ebcd50e76c559512539fd7c864fd2407 8265795: vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java fails when running with JEP 416 Reviewed-by: sspitsyn, dholmes ! src/hotspot/share/prims/unsafe.cpp ! test/hotspot/jtreg/ProblemList.txt + test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java + test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/libVMObjectAlloc.cpp Changeset: e3911a85 Author: Alexey Semenyuk Date: 2021-11-22 18:04:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3911a8532e9b93ba5e65c613bd79864485db5ce 8277429: Conflicting jpackage static library name Reviewed-by: almatvee, herrick, erikj ! make/modules/jdk.jpackage/Lib.gmk ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxAppImageBuilder.java Changeset: 6cf4cd1a Author: Coleen Phillimore Date: 2021-11-22 18:08:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cf4cd1aa46414d9af17f3704b27d0d381a17ee8 8273341: Update Siphash to version 1.0 Reviewed-by: dholmes ! src/hotspot/share/classfile/altHashing.cpp ! src/hotspot/share/classfile/altHashing.hpp Changeset: 851a3624 Author: Alexander Zuev Date: 2021-11-22 18:26:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/851a36247937d124e8217deaaa1a1831cba19b6e 8264297: Create implementation for NSAccessibilityProgressIndicator protocol peer Reviewed-by: pbansal ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m = src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ProgressIndicatorAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ProgressIndicatorAccessibility.m Changeset: 1049aba1 Author: Daniel D. Daugherty Date: 2021-11-22 19:03:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1049aba1fb65fd70bd723c80a84250512a68d653 8277576: ProblemList runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64 8277577: ProblemList compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java on linux-aarch64 8277578: ProblemList applications/jcstress/acqrel.java on linux-aarch64 Reviewed-by: mikael ! test/hotspot/jtreg/ProblemList.txt Changeset: 05a9a51d Author: Dean Long Date: 2021-11-22 20:50:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/05a9a51dbfc46eb52bc28f1f9a618c75ee2597e9 8277423: ciReplay: hidden class with comment expected error Reviewed-by: chagedorn, thartmann ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp Changeset: f62b81c3 Author: Dean Long Date: 2021-11-22 23:17:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f62b81c3b5e34895e06bedec137bcef701d49df6 8273095: vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java fails with "wrong OOME" Reviewed-by: shade, stefank ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/Test.java Changeset: bb11c55d Author: Hamlin Li Date: 2021-11-23 00:58:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb11c55dff86706a010c93ee2cc60c87bb2d53b6 8277542: G1: Move G1CardSetFreePool and related classes to separate files Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp + src/hotspot/share/gc/g1/g1SegmentedArrayFreePool.cpp + src/hotspot/share/gc/g1/g1SegmentedArrayFreePool.hpp Changeset: 12f08ba4 Author: Jaikiran Pai Date: 2021-11-23 08:19:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12f08ba4d47cb70a0629b17bc3639ce170309f21 8277507: Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java Changeset: e3243ee9 Author: Sergey Bylokhov Date: 2021-11-23 08:57:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3243ee963d074c892a0ed16a00fd91b440c96ac 8277087: ZipException: zip END header not found at ZipFile#Source.findEND Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java + test/jdk/java/util/zip/ZipOutputStream/EmptyComment.java Changeset: 79350b9b Author: Volker Simonis Date: 2021-11-23 09:15:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/79350b9b4f42e43a8ab27ea76b9115dae6f448af 8276216: Negated character classes performance regression in Pattern Reviewed-by: clanger ! src/java.base/share/classes/java/util/regex/Pattern.java + test/micro/org/openjdk/bench/java/util/regex/FindPattern.java Changeset: 017df140 Author: Albert Mingkun Yang Date: 2021-11-23 10:56:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/017df140ba65058270c5184db82162d42e42b908 8277556: Call ReferenceProcessorPhaseTimes::set_processing_is_mt once Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/shared/referenceProcessor.cpp Changeset: 36b887a8 Author: Albert Mingkun Yang Date: 2021-11-23 10:57:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36b887a885c76ddbbb1e21b32b8e7d9cc92f6ce2 8277560: Remove WorkerDataArray::_is_serial Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/shared/workerDataArray.cpp ! src/hotspot/share/gc/shared/workerDataArray.hpp ! src/hotspot/share/gc/shared/workerDataArray.inline.hpp Changeset: 66eaf652 Author: Andrey Turbanov Committer: Thomas Schatzl Date: 2021-11-23 12:33:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/66eaf6526126eb27c18acc64c2bb0791142815c9 8277413: Remove unused local variables in jdk.hotspot.agent Reviewed-by: lmesnik, tschatzl, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/StubQueue.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugInfoBuilder.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 90f96fb4 Author: Tobias Hartmann Date: 2021-11-23 12:46:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90f96fb4db174e50cc2510f292fe69fc995add26 8277441: CompileQueue::add fails with assert(_last->next() == __null) failed: not last Reviewed-by: chagedorn, neliasso ! src/hotspot/share/compiler/compileBroker.cpp Changeset: f4dc03ea Author: Erik ?sterlund Date: 2021-11-23 14:34:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper Reviewed-by: pliden, stefank ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zHeapIterator.hpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/services/heapDumper.cpp Changeset: 5e7e2da2 Author: Roger Riggs Date: 2021-11-23 15:02:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e7e2da227cd2b5e2d3d1e2f59fb74ddd1835abb 8272042: java.util.ImmutableCollections$Map1 and MapN should not be @ValueBased Reviewed-by: mchung, iris, naoto, smarks ! src/java.base/share/classes/java/util/ImmutableCollections.java Changeset: 64bdc843 Author: Daniel D. Daugherty Date: 2021-11-23 15:16:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/64bdc843907634b24ab02b8d81a0f5048b46072c 8277649: [BACKOUT] JDK-8277507 Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures Reviewed-by: alanb, stefank ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java Changeset: 38802ad5 Author: Christian Hagedorn Date: 2021-11-23 15:22:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38802ad56a31efc90733cb75ea27f019e2c4f5a4 8254108: ciReplay: Support incremental inlining Reviewed-by: dlong, thartmann ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciReplay.hpp ! src/hotspot/share/opto/bytecodeInfo.cpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/parse.hpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/InliningBase.java + test/hotspot/jtreg/compiler/ciReplay/TestIncrementalInlining.java ! test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java Changeset: 7b67a49f Author: Vicente Romero Date: 2021-11-23 15:23:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b67a49f830b71ef129a4a3a9b0d994d58587edf 8261847: performance of java.lang.Record::toString should be improved Reviewed-by: jlaskey, redestad ! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java + test/langtools/tools/javac/records/BigRecordsToStringTest.java + test/micro/org/openjdk/bench/java/lang/runtime/ObjectMethods.java Changeset: 8a44e093 Author: Jan Lahoda Date: 2021-11-23 16:46:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a44e093dc3e192990fde8ab37ab08c737f06b39 8268725: jshell does not support the --enable-native-access option Reviewed-by: sundar ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties + test/langtools/jdk/jshell/ToolEnableNativeAccessTest.java Changeset: e8acac2a Author: Daniel D. Daugherty Date: 2021-11-23 17:08:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e8acac2aba30e8a172ca14509220ec06e833d4af 8277350: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java times out Reviewed-by: hseigel, dholmes, lmesnik ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java Changeset: 03206726 Author: Mandy Chung Date: 2021-11-23 17:14:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/032067264fd73cd2f338838d6178f8af24d228b0 8277451: java.lang.reflect.Field::set on static field with invalid argument type should throw IAE Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/reflect/FieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleBooleanFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleByteFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleCharacterFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleDoubleFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleFloatFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleIntegerFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleLongFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleObjectFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleShortFieldAccessorImpl.java + test/jdk/java/lang/reflect/Field/NegativeTest.java ! test/jdk/java/lang/reflect/MethodHandleAccessorsTest.java Changeset: ea85e01a Author: Liam Miller-Cushon Date: 2021-11-23 18:14:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea85e01a4c8db1bc48d590abc882dc6efe5b0f4a 8271623: Omit enclosing instance fields from inner classes that don't use it Reviewed-by: vromero, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! test/langtools/tools/javac/6521805/T6521805d.java ! test/langtools/tools/javac/6521805/T6521805d.out ! test/langtools/tools/javac/6521805/p/Outer.java ! test/langtools/tools/javac/ClassFileModifiers/MemberModifiers.out ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnnotatedExtendsTest.java ! test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassConstructorsTest.java ! test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java ! test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateSiblingsTest.java ! test/langtools/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java ! test/langtools/tools/javac/classfiles/attributes/Synthetic/ThisFieldTest.java ! test/langtools/tools/javac/diags/examples/ErrSyntheticNameConflict.java + test/langtools/tools/javac/optimizeOuterThis/DontOptimizeOuterThis.java + test/langtools/tools/javac/optimizeOuterThis/InnerClasses.java + test/langtools/tools/javac/optimizeOuterThis/OptimizeOuterThis.java ! test/langtools/tools/javap/AnnoTest.java Changeset: 24e586a0 Author: Andrew Leonard Date: 2021-11-23 18:28:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/24e586a04368a76cd9f37aa783b974b9e0351d58 8276764: Enable deterministic file content ordering for Jar and Jmod Reviewed-by: mchung, ihse ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java + test/jdk/tools/jar/ContentOrder.java ! test/jdk/tools/jmod/JmodTest.java Changeset: 7cb56a23 Author: Leonid Mesnik Date: 2021-11-23 19:27:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7cb56a230dbd52935ae48fe44b4192ae3b4d7adb 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with JEP 416 Reviewed-by: cjplummer, mchung ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002a.java Changeset: 7b2d823e Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-23 20:05:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b2d823e842e6a66dbe46b048da44ca9e5485c75 8277503: compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java failed with "OnSpinWaitInst with the expected value 'isb' not found." Reviewed-by: chagedorn, aph, phh ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java Changeset: 712b8756 Author: Stefan Karlsson Date: 2021-11-24 08:25:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/712b8756828c88d4f71292d19fddb598d188c429 8277397: ZGC: Add JFR event for temporary latency measurements Reviewed-by: eosterlund, jbachorik, pliden, mgronlun ! src/hotspot/share/gc/z/zTracer.cpp ! src/hotspot/share/gc/z/zTracer.hpp ! src/hotspot/share/gc/z/zTracer.inline.hpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc Changeset: 6d734604 Author: Stefan Karlsson Date: 2021-11-24 08:26:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6d734604a38447d81df36f4d4ca57ce71bd570af 8277399: ZGC: Move worker thread logging out of gc+phase=debug Reviewed-by: eosterlund, pliden ! src/hotspot/share/gc/z/zStat.cpp Changeset: d085c2b8 Author: Jan Lahoda Date: 2021-11-24 10:07:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d085c2b8a790a5ddfbb01a0ea4edd4051cfb704b 8273328: Compiler implementation for Pattern Matching for switch (Second Preview) Reviewed-by: vromero, mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! test/langtools/tools/javac/patterns/Domination.java ! test/langtools/tools/javac/patterns/Domination.out ! test/langtools/tools/javac/patterns/EnumTypeChanges.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java ! test/langtools/tools/javac/patterns/SwitchErrors.java ! test/langtools/tools/javac/patterns/SwitchErrors.out ! test/langtools/tools/javac/patterns/Switches.java Changeset: 8a8bc29f Author: Ludvig Janiuk Committer: Nils Eliasson Date: 2021-11-24 11:03:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a8bc29f203fa4aaa29303a778fd388e32ca651a 8277562: Remove dead method c1 If::swap_sux Reviewed-by: thartmann, neliasso ! src/hotspot/share/c1/c1_Instruction.hpp Changeset: 17e68caa Author: KIRIYAMA Takuya Committer: Tobias Hartmann Date: 2021-11-24 11:22:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/17e68caad727b04f5e7efde59fce960c66558504 8277042: add test for 8276036 to compiler/codecache Reviewed-by: chagedorn, thartmann + test/hotspot/jtreg/compiler/codecache/CodeCacheFullCountTest.java Changeset: 96e36071 Author: Maurizio Cimadamore Date: 2021-11-24 11:51:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96e36071b63b624d56739b014b457ffc48147c4f 8275063: Implementation of Foreign Function & Memory API (Second incubator) Reviewed-by: erikj, psandoz, jvernee, darcy ! make/test/JtregNativeJdk.gmk ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/prims/universalUpcallHandler.cpp ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/java/nio/Buffer.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! src/java.base/share/classes/sun/nio/ch/IOUtil.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/AbstractLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Addressable.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/GroupLayout.java - src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAccess.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryHandles.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java - src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayouts.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java + src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/NativeSymbol.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/PaddingLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SequenceLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SymbolLookup.java + src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/VaList.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractCLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LayoutPath.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryAddressImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/NativeSymbolImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/PlatformLayouts.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Scoped.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/BufferLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequence.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/UpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/UpcallStubs.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/TypeClass.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/TypeClass.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/TypeClass.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/WinVaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java ! test/hotspot/jtreg/gc/shenandoah/compiler/TestLinkToNativeRBP.java ! test/jdk/java/foreign/CallGeneratorHelper.java ! test/jdk/java/foreign/NativeTestHelper.java ! test/jdk/java/foreign/SafeFunctionAccessTest.java ! test/jdk/java/foreign/StdLibTest.java ! test/jdk/java/foreign/TestAdaptVarHandles.java - test/jdk/java/foreign/TestAddressHandle.java + test/jdk/java/foreign/TestArrayCopy.java ! test/jdk/java/foreign/TestArrays.java ! test/jdk/java/foreign/TestByteBuffer.java - test/jdk/java/foreign/TestCircularInit1.java - test/jdk/java/foreign/TestCircularInit2.java ! test/jdk/java/foreign/TestCondy.java ! test/jdk/java/foreign/TestDowncall.java ! test/jdk/java/foreign/TestFree.java ! test/jdk/java/foreign/TestFunctionDescriptor.java ! test/jdk/java/foreign/TestHandshake.java ! test/jdk/java/foreign/TestIllegalLink.java ! test/jdk/java/foreign/TestIntrinsics.java - test/jdk/java/foreign/TestLayoutAttributes.java ! test/jdk/java/foreign/TestLayoutConstants.java ! test/jdk/java/foreign/TestLayoutEquality.java ! test/jdk/java/foreign/TestLayoutPaths.java ! test/jdk/java/foreign/TestLayouts.java ! test/jdk/java/foreign/TestMemoryAccess.java + test/jdk/java/foreign/TestMemoryAccessInstance.java - test/jdk/java/foreign/TestMemoryAccessStatics.java ! test/jdk/java/foreign/TestMemoryAlignment.java - test/jdk/java/foreign/TestMemoryCopy.java + test/jdk/java/foreign/TestMemoryDereference.java ! test/jdk/java/foreign/TestMemoryHandleAsUnsigned.java ! test/jdk/java/foreign/TestMismatch.java ! test/jdk/java/foreign/TestNULLAddress.java ! test/jdk/java/foreign/TestNative.java ! test/jdk/java/foreign/TestNoForeignUnsafeOverride.java ! test/jdk/java/foreign/TestNulls.java - test/jdk/java/foreign/TestRebase.java ! test/jdk/java/foreign/TestReshape.java ! test/jdk/java/foreign/TestResourceScope.java ! test/jdk/java/foreign/TestRestricted.java ! test/jdk/java/foreign/TestScopedOperations.java ! test/jdk/java/foreign/TestSegmentAllocators.java + test/jdk/java/foreign/TestSegmentCopy.java + test/jdk/java/foreign/TestSegmentOffset.java + test/jdk/java/foreign/TestSegmentOverlap.java ! test/jdk/java/foreign/TestSegments.java ! test/jdk/java/foreign/TestSharedAccess.java ! test/jdk/java/foreign/TestSlices.java ! test/jdk/java/foreign/TestSpliterator.java ! test/jdk/java/foreign/TestStringEncoding.java ! test/jdk/java/foreign/TestSymbolLookup.java ! test/jdk/java/foreign/TestTypeAccess.java ! test/jdk/java/foreign/TestUnsupportedPlatform.java ! test/jdk/java/foreign/TestUpcall.java ! test/jdk/java/foreign/TestUpcallException.java ! test/jdk/java/foreign/TestUpcallHighArity.java ! test/jdk/java/foreign/TestUpcallStructScope.java ! test/jdk/java/foreign/TestVarArgs.java ! test/jdk/java/foreign/TestVarHandleCombinators.java ! test/jdk/java/foreign/ThrowingUpcall.java ! test/jdk/java/foreign/callarranger/TestAarch64CallArranger.java ! test/jdk/java/foreign/callarranger/TestWindowsCallArranger.java ! test/jdk/java/foreign/channels/AbstractChannelsTest.java ! test/jdk/java/foreign/channels/TestAsyncSocketChannels.java ! test/jdk/java/foreign/channels/TestSocketChannels.java ! test/jdk/java/foreign/enablenativeaccess/org/openjdk/foreigntest/PanamaMainUnnamedModule.java ! test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/PanamaMain.java ! test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/PanamaMainInvoke.java ! test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/PanamaMainReflection.java ! test/jdk/java/foreign/handles/invoker_module/handle/invoker/MethodHandleInvoker.java ! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java + test/jdk/java/foreign/libAsyncInvokers.cpp ! test/jdk/java/foreign/libIntrinsics.c ! test/jdk/java/foreign/libSafeAccess.c + test/jdk/java/foreign/loaderLookup/TestLoaderLookup.java + test/jdk/java/foreign/loaderLookup/invoker/Invoker.java + test/jdk/java/foreign/loaderLookup/lookup/Lookup.java + test/jdk/java/foreign/loaderLookup/lookup/libFoo.c ! test/jdk/java/foreign/malloc/TestMixedMallocFree.java ! test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java ! test/jdk/java/foreign/stackwalk/TestStackWalk.java ! test/jdk/java/foreign/valist/VaListTest.java ! test/jdk/java/foreign/virtual/TestVirtualCalls.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/BulkMismatchAcquire.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/BulkOps.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/CLayouts.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadConstant.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadHelper.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadVirtual.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/JNICB.h + test/micro/org/openjdk/bench/jdk/incubator/foreign/JNICB.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverConstant.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNew.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNewHeap.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstant.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantFP.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantHeap.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantMapped.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantShared.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverPollutedBuffer.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverPollutedSegments.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/ParallelSum.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/QSort.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/StrLenTest.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/TestAdaptVarHandles.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/TestLoadBytes.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/UnrolledAccess.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/Upcalls.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/VaList.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/VarHandleExact.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libCallOverhead.c + test/micro/org/openjdk/bench/jdk/incubator/foreign/libJNICB.c + test/micro/org/openjdk/bench/jdk/incubator/foreign/libQSort.c + test/micro/org/openjdk/bench/jdk/incubator/foreign/libQSortJNI.c ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libUpcallsJNI.c ! test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java ! test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreBytes.java ! test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreShort.java Changeset: cf7adae6 Author: Thomas Stuefe Date: 2021-11-24 12:12:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf7adae6333c7446048ef0364737927337631f63 8275320: NMT should perform buffer overrun checks 8275320: NMT should perform buffer overrun checks 8275301: Unify C-heap buffer overrun checks into NMT Reviewed-by: simonis, zgu ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/services/mallocSiteTable.cpp ! src/hotspot/share/services/mallocSiteTable.hpp ! src/hotspot/share/services/mallocTracker.cpp ! src/hotspot/share/services/mallocTracker.hpp ! src/hotspot/share/services/memTracker.hpp ! src/hotspot/share/utilities/debug.cpp + test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp ! test/hotspot/gtest/testutils.cpp ! test/hotspot/gtest/testutils.hpp ! test/hotspot/gtest/unittest.hpp Changeset: 0384739a Author: Roger Riggs Date: 2021-11-24 15:14:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0384739afc2d470ab6a3525e9d85aca0af58f2ed 8276665: ObjectInputStream.GetField.get(name, object) should throw ClassNotFoundException Reviewed-by: naoto, lancea, smarks ! src/java.base/share/classes/java/io/ObjectInputStream.java + test/jdk/java/io/Serializable/GetField/ReadFieldsCNF.java Changeset: 663e33de Author: Christian Stein Committer: Jonathan Gibbons Date: 2021-11-24 16:50:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/663e33de13788586fa49bd9816bd148e58ad1031 8272728: javac ignores any -J option in @argfiles silently Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! test/langtools/tools/javac/options/modes/AtFilesTest.java Changeset: 951247c8 Author: Adam Sotona Date: 2021-11-24 17:03:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/951247c8cb4ea898bf7c188bed8e143ca7417c83 8235876: Misleading warning message in java source-file mode Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java ! test/langtools/tools/javac/launcher/SourceLauncherTest.java Changeset: 077b2de0 Author: Andrey Turbanov Committer: Vicente Romero Date: 2021-11-24 18:47:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/077b2de088665b907dbfc2b0522a1e109d1d2ca3 8274161: Cleanup redundant casts in jdk.compiler Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java Changeset: 96fe1d0d Author: Leonid Mesnik Date: 2021-11-24 20:11:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96fe1d0d4d95d87950ff2ecec570a927d831746e 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" Reviewed-by: sspitsyn, dholmes ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_tools.cpp Changeset: e785f699 Author: Pavel Rappo Date: 2021-11-24 20:13:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e785f699614abc8d557be8fc1782a1f86f272430 8276124: Provide snippet support for properties files Co-authored-by: Jonathan Gibbons Co-authored-by: Hannes Walln?fer Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/SnippetTester.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestLangProperties.java Changeset: b5841ba3 Author: Lance Andersen Date: 2021-11-24 20:42:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b5841ba3f3d079f3cfee532a4e7f23b00f5cd063 8277806: 4 tools/jar failures per platform after JDK-8272728 Reviewed-by: alanb, jjg ! test/jdk/tools/jar/modularJar/Basic.java ! test/jdk/tools/jar/multiRelease/MRTestBase.java Changeset: 26472bd3 Author: Daniel D. Daugherty Date: 2021-11-24 22:27:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/26472bd3bd8788b0839e2871ed220e438fb6d608 8277811: ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java 8277813: ProblemList vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/TestDescription.java Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList.txt Changeset: a81e4fc0 Author: Jaikiran Pai Date: 2021-11-25 02:12:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a81e4fc07b654a3cc954921981d9d3c0cfd8bcec 8258117: jar tool sets the time stamp of module-info.class entries to the current time Reviewed-by: lancea, ihse, alanb ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java + test/jdk/tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java Changeset: 21e302a0 Author: Daniel D. Daugherty Date: 2021-11-25 04:27:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/21e302a0f4cbf3ace907c36d871a2f2cf6277188 8270435: UT: MonitorUsedDeflationThresholdTest failed: did not find too_many string in output Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/Monitor/MonitorUsedDeflationThresholdTest.java Changeset: f0136ec9 Author: Fairoz Matte Committer: Christian Hagedorn Date: 2021-11-25 08:37:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f0136ec94539d0e30ec11d44f8143196da1f7125 8275687: runtime/CommandLine/PrintTouchedMethods test shouldn't catch RuntimeException Reviewed-by: iklam, chagedorn ! test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethodsJcmd.java Changeset: 3034ae87 Author: Erik ?sterlund Date: 2021-11-25 09:50:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3034ae87ce4b94c7dc40cfb5a96d6d1e87910bbf 8277631: ZGC: CriticalMetaspaceAllocation asserts Reviewed-by: pliden, stefank, dholmes ! src/hotspot/share/memory/metaspaceCriticalAllocation.cpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/LoadUnloadGC/LoadUnloadGC.java Changeset: f7888349 Author: Ivan Walulya Date: 2021-11-25 14:10:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f788834998eeb9083e971857446321ed173aa916 8277786: G1: Rename log2_card_region_per_heap_region used in G1CardSet Reviewed-by: ayang, tschatzl, mli ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp Changeset: 98799204 Author: Albert Mingkun Yang Date: 2021-11-25 14:54:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/987992042454f92936d3efbd01e7beb921e3b70e 8277825: Remove unused ReferenceProcessorPhaseTimes::_sub_phases_total_time_ms Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp ! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.hpp Changeset: eb4d886b Author: Andrey Turbanov Committer: Sergey Bylokhov Date: 2021-11-26 01:45:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb4d886bc0f57085b21ef41f2069ff60b2714cfa 8277504: Use String.stripTrailing instead of hand-crafted method in SwingUtilities2 Reviewed-by: pbansal, serb ! src/java.desktop/share/classes/sun/swing/SwingUtilities2.java Changeset: 7e54d065 Author: Mandy Chung Date: 2021-11-26 01:55:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e54d065a17f1277adf1b8561fadb8a480bc6bed 8277165: jdeps --multi-release --print-module-deps fails if module-info.class in different versioned directories 8277166: Data race in jdeps VersionHelper 8277123: jdeps does not report some exceptions correctly Reviewed-by: jvernee, alanb ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/MultiReleaseException.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java + test/langtools/tools/jdeps/multiVersion/MultiVersionError.java + test/langtools/tools/jdeps/multiVersion/src/m1/module-info.java + test/langtools/tools/jdeps/multiVersion/src/m1/p/Test.java + test/langtools/tools/jdeps/multiVersion/src/m1/p/internal/P.java + test/langtools/tools/jdeps/multiVersion/src/m2/module-info.java + test/langtools/tools/jdeps/multiVersion/src/m2/p/internal/P.java + test/langtools/tools/jdeps/multiVersion/src/m2/q/Q.java Changeset: 3383c0dc Author: Stuart Monteith Committer: Nick Gasson Date: 2021-11-26 09:02:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3383c0dcc016715dcb350b6ba196a7cdc833cdc6 8277659: [TESTBUG] Microbenchmark ThreadOnSpinWaitProducerConsumer.java hangs Reviewed-by: njian, ngasson ! test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitProducerConsumer.java Changeset: 00a6238d Author: Yadong Wang Committer: Fei Yang Date: 2021-11-26 09:09:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00a6238daed4a4aaa6001275ce620646cdabfeb5 8277508: need to check has_predicated_vectors before calling scalable_predicate_reg_slots Reviewed-by: njian, thartmann, ngasson ! src/hotspot/share/opto/matcher.cpp Changeset: 99e4bda3 Author: Roman Kennke Date: 2021-11-26 09:46:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99e4bda303f2c71972a125d0ecaf4cf986c8614a 8277417: C1 LIR instruction for load-klass Reviewed-by: iveresov, mdoerr, ngasson, aph ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRAssembler.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/gc/shared/c1/barrierSetC1.cpp Changeset: 3e798dd4 Author: Roland Westrelin Date: 2021-11-26 09:48:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3e798dd40c68439f3220445e679b9e0e495435d8 8275330: C2: assert(n->is_Root() || n->is_Region() || n->is_Phi() || n->is_MachMerge() || def_block->dominates(block)) failed: uses must be dominated by definitions Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/opaquenode.cpp ! src/hotspot/share/opto/opaquenode.hpp + test/hotspot/jtreg/compiler/loopopts/TestDeadPostLoopBecausePredicate.java Changeset: 040b2c52 Author: Ludvig Janiuk Committer: Nils Eliasson Date: 2021-11-26 09:52:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/040b2c52d3e82048630fbd45a7db48a5e65204b7 8277139: Improve code readability in PredecessorValidator (c1_IR.cpp) Reviewed-by: thartmann, chagedorn ! src/hotspot/share/c1/c1_IR.cpp Changeset: ddb61725 Author: duke Date: 2021-11-26 11:00:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ddb61725746c50473090ec1467c2c42538691aa7 Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Nov 26 11:07:39 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 26 Nov 2021 11:07:39 GMT Subject: [foreign-memaccess+abi] RFR: Merge master Message-ID: Hi all, this is an _automatically_ generated pull request to notify you that there are 84 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: Over 60 files contains merge conflicts. All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. # Ensure target branch is up to date $ git checkout foreign-memaccess+abi $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi # Fetch and checkout the branch for this pull request $ git fetch https://github.com/openjdk-bot/panama-foreign.git +107:openjdk-bot-107 $ git checkout openjdk-bot-107 # Merge the target branch $ git merge foreign-memaccess+abi When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: $ git add paths/to/files/with/conflicts $ git commit -m 'Merge master' When you have created the merge commit, run the following command to push the merge commit to this pull request: $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-107:107 _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. Thanks, J. Duke ------------- Commit messages: - Automatic merge of jdk:master into master - 8277139: Improve code readability in PredecessorValidator (c1_IR.cpp) - 8275330: C2: assert(n->is_Root() || n->is_Region() || n->is_Phi() || n->is_MachMerge() || def_block->dominates(block)) failed: uses must be dominated by definitions - 8277417: C1 LIR instruction for load-klass - 8277508: need to check has_predicated_vectors before calling scalable_predicate_reg_slots - 8277659: [TESTBUG] Microbenchmark ThreadOnSpinWaitProducerConsumer.java hangs - 8277165: jdeps --multi-release --print-module-deps fails if module-info.class in different versioned directories - 8277504: Use String.stripTrailing instead of hand-crafted method in SwingUtilities2 - 8277825: Remove unused ReferenceProcessorPhaseTimes::_sub_phases_total_time_ms - 8277786: G1: Rename log2_card_region_per_heap_region used in G1CardSet - ... and 74 more: https://git.openjdk.java.net/panama-foreign/compare/21d73270...ddb61725 The webrev contains the conflicts with foreign-memaccess+abi: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=618&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/618/files Stats: 24429 lines in 496 files changed: 14733 ins; 6163 del; 3533 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/618.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/618/head:pull/618 PR: https://git.openjdk.java.net/panama-foreign/pull/618 From duke at openjdk.java.net Fri Nov 26 14:36:57 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 26 Nov 2021 14:36:57 GMT Subject: [foreign-memaccess+abi] RFR: Merge master [v2] In-Reply-To: References: Message-ID: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 84 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > Over 60 files contains merge conflicts. > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-memaccess+abi > $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +107:openjdk-bot-107 > $ git checkout openjdk-bot-107 > > # Merge the target branch > $ git merge foreign-memaccess+abi > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-107:107 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke J. Duke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 85 commits: - Merge branch 'foreign-memaccess+abi' into openjdk-bot-107 All test passes - but the call arranger tests - Automatic merge of jdk:master into master - 8277139: Improve code readability in PredecessorValidator (c1_IR.cpp) Reviewed-by: thartmann, chagedorn - 8275330: C2: assert(n->is_Root() || n->is_Region() || n->is_Phi() || n->is_MachMerge() || def_block->dominates(block)) failed: uses must be dominated by definitions Reviewed-by: thartmann, chagedorn - 8277417: C1 LIR instruction for load-klass Reviewed-by: iveresov, mdoerr, ngasson, aph - 8277508: need to check has_predicated_vectors before calling scalable_predicate_reg_slots Reviewed-by: njian, thartmann, ngasson - 8277659: [TESTBUG] Microbenchmark ThreadOnSpinWaitProducerConsumer.java hangs Reviewed-by: njian, ngasson - 8277165: jdeps --multi-release --print-module-deps fails if module-info.class in different versioned directories 8277166: Data race in jdeps VersionHelper 8277123: jdeps does not report some exceptions correctly Reviewed-by: jvernee, alanb - 8277504: Use String.stripTrailing instead of hand-crafted method in SwingUtilities2 Reviewed-by: pbansal, serb - 8277825: Remove unused ReferenceProcessorPhaseTimes::_sub_phases_total_time_ms Reviewed-by: tschatzl - ... and 75 more: https://git.openjdk.java.net/panama-foreign/compare/77dbcdb8...ea95bf47 ------------- Changes: https://git.openjdk.java.net/panama-foreign/pull/618/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=618&range=01 Stats: 10424 lines in 359 files changed: 8116 ins; 1134 del; 1174 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/618.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/618/head:pull/618 PR: https://git.openjdk.java.net/panama-foreign/pull/618 From duke at openjdk.java.net Fri Nov 26 14:48:54 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 26 Nov 2021 14:48:54 GMT Subject: [foreign-memaccess+abi] RFR: Merge master [v3] In-Reply-To: References: Message-ID: <2VaNzYYoQi9ZOSIS_awyGnVtb9ig11xYa1CbJITXfKg=.56605962-af24-4dfc-85b6-3a6735d5486f@github.com> > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 84 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > Over 60 files contains merge conflicts. > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-memaccess+abi > $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +107:openjdk-bot-107 > $ git checkout openjdk-bot-107 > > # Merge the target branch > $ git merge foreign-memaccess+abi > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-107:107 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke J. Duke has updated the pull request incrementally with one additional commit since the last revision: Fix issue in function descriptor ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/618/files - new: https://git.openjdk.java.net/panama-foreign/pull/618/files/ea95bf47..4afbaca4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=618&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=618&range=01-02 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/618.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/618/head:pull/618 PR: https://git.openjdk.java.net/panama-foreign/pull/618 From duke at openjdk.java.net Fri Nov 26 14:54:23 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 26 Nov 2021 14:54:23 GMT Subject: [foreign-memaccess+abi] Integrated: Merge master In-Reply-To: References: Message-ID: On Fri, 26 Nov 2021 11:01:11 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 84 commits from the branch `master`that can **not** be merged into the branch `foreign-memaccess+abi`: > > Over 60 files contains merge conflicts. > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > > # Ensure target branch is up to date > $ git checkout foreign-memaccess+abi > $ git pull https://github.com/openjdk/panama-foreign.git foreign-memaccess+abi > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +107:openjdk-bot-107 > $ git checkout openjdk-bot-107 > > # Merge the target branch > $ git merge foreign-memaccess+abi > > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge master' > > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-107:107 > > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke This pull request has now been integrated. Changeset: ac67414d Author: J. Duke Committer: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/ac67414d41ac8dc6e59d947a57f45b109b22d78d Stats: 10424 lines in 359 files changed: 8117 ins; 1130 del; 1177 mod Merge master ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/618 From duke at openjdk.java.net Fri Nov 26 15:02:32 2021 From: duke at openjdk.java.net (duke) Date: Fri, 26 Nov 2021 15:02:32 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 86 new changesets Message-ID: <81f58079-bf1f-4608-925a-4c034377c911@openjdk.org> Changeset: 03debf27 Author: Daniel Fuchs Date: 2021-11-19 13:18:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/03debf277537135974d3f55e3a5c7cf6842ee5e0 8276774: Cookie stored in CookieHandler not sent if user headers contain cookie Reviewed-by: michaelm ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java ! src/java.net.http/share/classes/jdk/internal/net/http/Stream.java ! test/jdk/java/net/httpclient/CookieHeaderTest.java = test/jdk/java/net/httpclient/UserCookieTest.java Changeset: b1a1bf4e Author: Claes Redestad Date: 2021-11-19 13:25:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b1a1bf4e305d6675f8f751aa8fef7013d99466f1 8277427: Update jib-profiles.js to use JMH 1.33 devkit Reviewed-by: shade, erikj ! make/conf/jib-profiles.js Changeset: a0227965 Author: Magnus Ihse Bursie Committer: Magnus Ihse Bursie Date: 2021-11-19 13:55:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a0227965bb8d1d49718794d67f8a4cfeebc9bec2 8275745: Reproducible copyright headers Reviewed-by: ihse, erikj ! make/autoconf/basic_tools.m4 ! make/autoconf/jdk-options.m4 ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/jdk/src/classes/build/tools/cldrconverter/CopyrightHeaders.java ! make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java ! make/modules/java.base/Gensrc.gmk ! make/modules/jdk.localedata/Gensrc.gmk Changeset: 936f7ff4 Author: Andy Herrick Date: 2021-11-19 14:23:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/936f7ff49ed86adb74bb1ff10d93cb3d7f7d70a0 8276150: Quarantined jpackage apps are labeled as "damaged" Reviewed-by: almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java Changeset: 03f8c0fb Author: Sean Mullan Date: 2021-11-19 14:36:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/03f8c0fb9363dc1bb07bed1ae0359c029caa0130 8275887: jarsigner prints invalid digest/signature algorithm warnings if keysize is weak/disabled Reviewed-by: weijun ! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java ! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java ! src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java Changeset: 976c2bb0 Author: Stefan Karlsson Date: 2021-11-19 15:34:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/976c2bb05611cdc7b11b0918aaf50ff693507aae 8277212: GC accidentally cleans valid megamorphic vtable inline caches Reviewed-by: eosterlund, pliden, coleenp, thartmann ! src/hotspot/share/code/compiledMethod.cpp Changeset: 09e8c8c6 Author: Coleen Phillimore Date: 2021-11-19 17:48:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/09e8c8c64abf4178a042c79b92d7e08e54467331 8277342: vmTestbase/nsk/stress/strace/strace004.java fails with SIGSEGV in InstanceKlass::jni_id_for Reviewed-by: dholmes, hseigel ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 66775543 Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:48:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6677554374ade32c9f2ddaaa093064de8aebd831 8274949: Use String.contains() instead of String.indexOf() in java.base Reviewed-by: weijun, dfuchs, vtewari, lancea ! src/java.base/share/classes/java/net/HttpCookie.java ! src/java.base/share/classes/java/net/HttpURLConnection.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/sun/net/www/http/HttpCapture.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java ! src/java.base/share/classes/sun/security/rsa/RSAUtil.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/Debug.java ! src/java.base/share/classes/sun/security/util/SignatureUtil.java ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java ! src/java.base/share/classes/sun/util/locale/LocaleMatcher.java ! src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: 36b59f38 Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:49:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36b59f3814fdaa44c9c04a0e8d63d0ba56929326 8274333: Redundant null comparison after Pattern.split Reviewed-by: mullan, weijun, rriggs, iris ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java Changeset: f609b8fd Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:50:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f609b8fd74c55f3149d8e5a6a9a9bc3598c0b961 8274946: Cleanup unnecessary calls to Throwable.initCause() in java.rmi Reviewed-by: iris, rriggs ! src/java.rmi/share/classes/java/rmi/server/RMIClassLoader.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java ! src/java.rmi/share/classes/javax/rmi/ssl/SslRMIClientSocketFactory.java ! src/java.rmi/share/classes/javax/rmi/ssl/SslRMIServerSocketFactory.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java Changeset: e47cc81b Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:51:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e47cc81b095381266104e9137495e91fb4c225a4 8275386: Change nested classes in jdk.jlink to static nested classes Reviewed-by: alanb, rriggs, iris ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolManager.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java Changeset: a3406a1d Author: Thomas Stuefe Date: 2021-11-19 19:49:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a3406a1d8ab4228b06b4f2978f87275093c39468 8277092: TestMetaspaceAllocationMT2.java#ndebug-default fails with "RuntimeException: Committed seems high: NNNN expected at most MMMM" Reviewed-by: coleenp ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestContext.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestManyArenasManyThreads.java Changeset: 2d4af225 Author: Yasumasa Suenaga Date: 2021-11-19 20:24:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2d4af2255feb2eaeca533424f8cba3ec0945d757 8277370: configure script cannot distinguish WSL version Reviewed-by: erikj ! make/autoconf/basic_windows.m4 Changeset: 2ab43ec2 Author: Pavel Rappo Date: 2021-11-19 20:51:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2ab43ec2428edaebfe9a7fb0e716ff7141a28de0 8273544: Increase test coverage for snippets Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attributes.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Replace.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Style.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/SnippetTester.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetPathOption.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: c79a485f Author: Daniel D. Daugherty Date: 2021-11-19 22:37:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c79a485f1c3f9c0c3a79b8847fdcd50a141cd529 8277494: [BACKOUT] JDK-8276150 Quarantined jpackage apps are labeled as "damaged" Reviewed-by: asemenyuk, tschatzl ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java Changeset: 1d7cef33 Author: Derek White Date: 2021-11-20 00:48:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1d7cef33c5ff24695463a03c58c7ca350ec190fc 8276662: Scalability bottleneck in SymbolTable::lookup_common() Reviewed-by: redestad, dholmes, iklam, shade ! src/hotspot/share/classfile/symbolTable.cpp Changeset: 1c215f33 Author: Vishal Chand Committer: Thomas Schatzl Date: 2021-11-20 10:03:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c215f33698ba2aef4fb230475a9bd33ed3005f9 8272773: Configurable card table card size Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1Arguments.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/objectStartArray.cpp ! src/hotspot/share/gc/parallel/objectStartArray.hpp ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.hpp ! src/hotspot/share/gc/shared/cardTable.cpp ! src/hotspot/share/gc/shared/cardTable.hpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/genArguments.cpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.hpp Changeset: 0a9e76c4 Author: Jie Fu Date: 2021-11-20 10:12:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0a9e76c4f9d966015c19e87e3eb59ceb7489459f 8277485: Zero: Fix _fast_{i,f}access_0 bytecodes handling Reviewed-by: sgehwolf, shade ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 4ff43010 Author: Joe Darcy Date: 2021-11-21 20:42:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ff43010bb3f92bd58f66be52a086b3d078b0cbb 8224922: Access JavaFileObject from Element(s) Co-authored-by: Jan Lahoda Reviewed-by: jjg ! src/java.compiler/share/classes/javax/annotation/processing/Filer.java ! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java ! src/java.compiler/share/classes/javax/lang/model/element/package-info.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java + test/langtools/tools/javac/processing/model/element/TestFileObjectOf.java ! test/langtools/tools/javac/tree/NoPrivateTypesExported.java Changeset: ca31ed53 Author: TatWai Chong Date: 2021-11-22 02:31:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ca31ed5335f6fa7229c94ba20d9d6031b930d69a 8275448: [REDO] AArch64: Implement string_compare intrinsic in SVE Reviewed-by: ngasson, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/register_definitions_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp + test/micro/org/openjdk/bench/java/lang/StringCompareToDifferentLength.java Changeset: 3f847fe8 Author: Aleksey Shipilev Date: 2021-11-22 09:09:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f847fe89a088d6921107ca887a7a1bace871bd6 8277385: Zero: Enable CompactStrings support Reviewed-by: redestad, adinn ! src/hotspot/cpu/zero/globals_zero.hpp Changeset: 8051041e Author: Albert Mingkun Yang Date: 2021-11-22 09:59:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8051041eb2b3d70d4cc62b6f2726279d51e44733 8277534: Remove unused ReferenceProcessor::has_discovered_references Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 32839ba0 Author: Serguei Spitsyn Date: 2021-11-22 10:47:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32839ba012f0a0a66e249cd8d12b94499d82ec0a 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" Reviewed-by: mdoerr, lmesnik, dcubed ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: d427c79d Author: Hamlin Li Date: 2021-11-22 11:27:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d427c79d3bd6c80b67c10d15a461f13ae7e0f84b 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp Changeset: 6b4fbaed Author: Jim Laskey Date: 2021-11-22 16:17:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6b4fbaedbb782c5f028735ac1d92838895589192 8273792: JumpableGenerator.rngs() documentation refers to wrong method Co-authored-by: Guy Steele Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/RandomGenerator.java Changeset: 8683de5e Author: Jim Laskey Date: 2021-11-22 16:19:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8683de5eda2d1a04f187073f969140245908f324 8274685: Documentation suggests there are ArbitrarilyJumpableGenerator when none Co-authored-by: Guy Steele Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/package-info.java Changeset: e5298655 Author: Jatin Bhateja Date: 2021-11-22 16:38:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e529865531d0eb5a2119a1d220b195d088794226 8277239: SIGSEGV in vrshift_reg_maskedNode::emit Reviewed-by: sviswanathan, dlong ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp Changeset: 22f12ac4 Author: Joe Darcy Date: 2021-11-22 16:59:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/22f12ac429fbbf134d182d9bf2a16a3d43bc71e1 8277522: Make formatting of null consistent in Elements Reviewed-by: jlahoda ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 33e2a518 Author: Leonid Mesnik Date: 2021-11-22 17:11:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/33e2a518ebcd50e76c559512539fd7c864fd2407 8265795: vmTestbase/nsk/jvmti/AttachOnDemand/attach022/TestDescription.java fails when running with JEP 416 Reviewed-by: sspitsyn, dholmes ! src/hotspot/share/prims/unsafe.cpp ! test/hotspot/jtreg/ProblemList.txt + test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java + test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/libVMObjectAlloc.cpp Changeset: e3911a85 Author: Alexey Semenyuk Date: 2021-11-22 18:04:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3911a8532e9b93ba5e65c613bd79864485db5ce 8277429: Conflicting jpackage static library name Reviewed-by: almatvee, herrick, erikj ! make/modules/jdk.jpackage/Lib.gmk ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxAppImageBuilder.java Changeset: 6cf4cd1a Author: Coleen Phillimore Date: 2021-11-22 18:08:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6cf4cd1aa46414d9af17f3704b27d0d381a17ee8 8273341: Update Siphash to version 1.0 Reviewed-by: dholmes ! src/hotspot/share/classfile/altHashing.cpp ! src/hotspot/share/classfile/altHashing.hpp Changeset: 851a3624 Author: Alexander Zuev Date: 2021-11-22 18:26:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/851a36247937d124e8217deaaa1a1831cba19b6e 8264297: Create implementation for NSAccessibilityProgressIndicator protocol peer Reviewed-by: pbansal ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m = src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ProgressIndicatorAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ProgressIndicatorAccessibility.m Changeset: 1049aba1 Author: Daniel D. Daugherty Date: 2021-11-22 19:03:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1049aba1fb65fd70bd723c80a84250512a68d653 8277576: ProblemList runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64 8277577: ProblemList compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java on linux-aarch64 8277578: ProblemList applications/jcstress/acqrel.java on linux-aarch64 Reviewed-by: mikael ! test/hotspot/jtreg/ProblemList.txt Changeset: 05a9a51d Author: Dean Long Date: 2021-11-22 20:50:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/05a9a51dbfc46eb52bc28f1f9a618c75ee2597e9 8277423: ciReplay: hidden class with comment expected error Reviewed-by: chagedorn, thartmann ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp Changeset: f62b81c3 Author: Dean Long Date: 2021-11-22 23:17:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f62b81c3b5e34895e06bedec137bcef701d49df6 8273095: vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java fails with "wrong OOME" Reviewed-by: shade, stefank ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/Test.java Changeset: bb11c55d Author: Hamlin Li Date: 2021-11-23 00:58:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb11c55dff86706a010c93ee2cc60c87bb2d53b6 8277542: G1: Move G1CardSetFreePool and related classes to separate files Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp + src/hotspot/share/gc/g1/g1SegmentedArrayFreePool.cpp + src/hotspot/share/gc/g1/g1SegmentedArrayFreePool.hpp Changeset: 12f08ba4 Author: Jaikiran Pai Date: 2021-11-23 08:19:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12f08ba4d47cb70a0629b17bc3639ce170309f21 8277507: Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java Changeset: e3243ee9 Author: Sergey Bylokhov Date: 2021-11-23 08:57:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3243ee963d074c892a0ed16a00fd91b440c96ac 8277087: ZipException: zip END header not found at ZipFile#Source.findEND Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java + test/jdk/java/util/zip/ZipOutputStream/EmptyComment.java Changeset: 79350b9b Author: Volker Simonis Date: 2021-11-23 09:15:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/79350b9b4f42e43a8ab27ea76b9115dae6f448af 8276216: Negated character classes performance regression in Pattern Reviewed-by: clanger ! src/java.base/share/classes/java/util/regex/Pattern.java + test/micro/org/openjdk/bench/java/util/regex/FindPattern.java Changeset: 017df140 Author: Albert Mingkun Yang Date: 2021-11-23 10:56:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/017df140ba65058270c5184db82162d42e42b908 8277556: Call ReferenceProcessorPhaseTimes::set_processing_is_mt once Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/shared/referenceProcessor.cpp Changeset: 36b887a8 Author: Albert Mingkun Yang Date: 2021-11-23 10:57:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/36b887a885c76ddbbb1e21b32b8e7d9cc92f6ce2 8277560: Remove WorkerDataArray::_is_serial Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/shared/workerDataArray.cpp ! src/hotspot/share/gc/shared/workerDataArray.hpp ! src/hotspot/share/gc/shared/workerDataArray.inline.hpp Changeset: 66eaf652 Author: Andrey Turbanov Committer: Thomas Schatzl Date: 2021-11-23 12:33:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/66eaf6526126eb27c18acc64c2bb0791142815c9 8277413: Remove unused local variables in jdk.hotspot.agent Reviewed-by: lmesnik, tschatzl, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/StubQueue.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugInfoBuilder.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 90f96fb4 Author: Tobias Hartmann Date: 2021-11-23 12:46:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90f96fb4db174e50cc2510f292fe69fc995add26 8277441: CompileQueue::add fails with assert(_last->next() == __null) failed: not last Reviewed-by: chagedorn, neliasso ! src/hotspot/share/compiler/compileBroker.cpp Changeset: f4dc03ea Author: Erik ?sterlund Date: 2021-11-23 14:34:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper Reviewed-by: pliden, stefank ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zHeapIterator.hpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/services/heapDumper.cpp Changeset: 5e7e2da2 Author: Roger Riggs Date: 2021-11-23 15:02:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e7e2da227cd2b5e2d3d1e2f59fb74ddd1835abb 8272042: java.util.ImmutableCollections$Map1 and MapN should not be @ValueBased Reviewed-by: mchung, iris, naoto, smarks ! src/java.base/share/classes/java/util/ImmutableCollections.java Changeset: 64bdc843 Author: Daniel D. Daugherty Date: 2021-11-23 15:16:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/64bdc843907634b24ab02b8d81a0f5048b46072c 8277649: [BACKOUT] JDK-8277507 Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures Reviewed-by: alanb, stefank ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java Changeset: 38802ad5 Author: Christian Hagedorn Date: 2021-11-23 15:22:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38802ad56a31efc90733cb75ea27f019e2c4f5a4 8254108: ciReplay: Support incremental inlining Reviewed-by: dlong, thartmann ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciReplay.hpp ! src/hotspot/share/opto/bytecodeInfo.cpp ! src/hotspot/share/opto/doCall.cpp ! src/hotspot/share/opto/parse.hpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/InliningBase.java + test/hotspot/jtreg/compiler/ciReplay/TestIncrementalInlining.java ! test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java Changeset: 7b67a49f Author: Vicente Romero Date: 2021-11-23 15:23:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b67a49f830b71ef129a4a3a9b0d994d58587edf 8261847: performance of java.lang.Record::toString should be improved Reviewed-by: jlaskey, redestad ! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java + test/langtools/tools/javac/records/BigRecordsToStringTest.java + test/micro/org/openjdk/bench/java/lang/runtime/ObjectMethods.java Changeset: 8a44e093 Author: Jan Lahoda Date: 2021-11-23 16:46:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a44e093dc3e192990fde8ab37ab08c737f06b39 8268725: jshell does not support the --enable-native-access option Reviewed-by: sundar ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties + test/langtools/jdk/jshell/ToolEnableNativeAccessTest.java Changeset: e8acac2a Author: Daniel D. Daugherty Date: 2021-11-23 17:08:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e8acac2aba30e8a172ca14509220ec06e833d4af 8277350: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java times out Reviewed-by: hseigel, dholmes, lmesnik ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java Changeset: 03206726 Author: Mandy Chung Date: 2021-11-23 17:14:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/032067264fd73cd2f338838d6178f8af24d228b0 8277451: java.lang.reflect.Field::set on static field with invalid argument type should throw IAE Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/reflect/FieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleBooleanFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleByteFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleCharacterFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleDoubleFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleFloatFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleIntegerFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleLongFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleObjectFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodHandleShortFieldAccessorImpl.java + test/jdk/java/lang/reflect/Field/NegativeTest.java ! test/jdk/java/lang/reflect/MethodHandleAccessorsTest.java Changeset: ea85e01a Author: Liam Miller-Cushon Date: 2021-11-23 18:14:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea85e01a4c8db1bc48d590abc882dc6efe5b0f4a 8271623: Omit enclosing instance fields from inner classes that don't use it Reviewed-by: vromero, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! test/langtools/tools/javac/6521805/T6521805d.java ! test/langtools/tools/javac/6521805/T6521805d.out ! test/langtools/tools/javac/6521805/p/Outer.java ! test/langtools/tools/javac/ClassFileModifiers/MemberModifiers.out ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnnotatedExtendsTest.java ! test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassConstructorsTest.java ! test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateInnerClassMembersTest.java ! test/langtools/tools/javac/classfiles/attributes/Synthetic/AccessToPrivateSiblingsTest.java ! test/langtools/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java ! test/langtools/tools/javac/classfiles/attributes/Synthetic/ThisFieldTest.java ! test/langtools/tools/javac/diags/examples/ErrSyntheticNameConflict.java + test/langtools/tools/javac/optimizeOuterThis/DontOptimizeOuterThis.java + test/langtools/tools/javac/optimizeOuterThis/InnerClasses.java + test/langtools/tools/javac/optimizeOuterThis/OptimizeOuterThis.java ! test/langtools/tools/javap/AnnoTest.java Changeset: 24e586a0 Author: Andrew Leonard Date: 2021-11-23 18:28:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/24e586a04368a76cd9f37aa783b974b9e0351d58 8276764: Enable deterministic file content ordering for Jar and Jmod Reviewed-by: mchung, ihse ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java + test/jdk/tools/jar/ContentOrder.java ! test/jdk/tools/jmod/JmodTest.java Changeset: 7cb56a23 Author: Leonid Mesnik Date: 2021-11-23 19:27:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7cb56a230dbd52935ae48fe44b4192ae3b4d7adb 8265796: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with JEP 416 Reviewed-by: cjplummer, mchung ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002a.java Changeset: 7b2d823e Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-23 20:05:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7b2d823e842e6a66dbe46b048da44ca9e5485c75 8277503: compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java failed with "OnSpinWaitInst with the expected value 'isb' not found." Reviewed-by: chagedorn, aph, phh ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java Changeset: 712b8756 Author: Stefan Karlsson Date: 2021-11-24 08:25:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/712b8756828c88d4f71292d19fddb598d188c429 8277397: ZGC: Add JFR event for temporary latency measurements Reviewed-by: eosterlund, jbachorik, pliden, mgronlun ! src/hotspot/share/gc/z/zTracer.cpp ! src/hotspot/share/gc/z/zTracer.hpp ! src/hotspot/share/gc/z/zTracer.inline.hpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc Changeset: 6d734604 Author: Stefan Karlsson Date: 2021-11-24 08:26:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6d734604a38447d81df36f4d4ca57ce71bd570af 8277399: ZGC: Move worker thread logging out of gc+phase=debug Reviewed-by: eosterlund, pliden ! src/hotspot/share/gc/z/zStat.cpp Changeset: d085c2b8 Author: Jan Lahoda Date: 2021-11-24 10:07:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d085c2b8a790a5ddfbb01a0ea4edd4051cfb704b 8273328: Compiler implementation for Pattern Matching for switch (Second Preview) Reviewed-by: vromero, mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! test/langtools/tools/javac/patterns/Domination.java ! test/langtools/tools/javac/patterns/Domination.out ! test/langtools/tools/javac/patterns/EnumTypeChanges.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java ! test/langtools/tools/javac/patterns/SwitchErrors.java ! test/langtools/tools/javac/patterns/SwitchErrors.out ! test/langtools/tools/javac/patterns/Switches.java Changeset: 8a8bc29f Author: Ludvig Janiuk Committer: Nils Eliasson Date: 2021-11-24 11:03:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a8bc29f203fa4aaa29303a778fd388e32ca651a 8277562: Remove dead method c1 If::swap_sux Reviewed-by: thartmann, neliasso ! src/hotspot/share/c1/c1_Instruction.hpp Changeset: 17e68caa Author: KIRIYAMA Takuya Committer: Tobias Hartmann Date: 2021-11-24 11:22:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/17e68caad727b04f5e7efde59fce960c66558504 8277042: add test for 8276036 to compiler/codecache Reviewed-by: chagedorn, thartmann + test/hotspot/jtreg/compiler/codecache/CodeCacheFullCountTest.java Changeset: 96e36071 Author: Maurizio Cimadamore Date: 2021-11-24 11:51:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96e36071b63b624d56739b014b457ffc48147c4f 8275063: Implementation of Foreign Function & Memory API (Second incubator) Reviewed-by: erikj, psandoz, jvernee, darcy ! make/test/JtregNativeJdk.gmk ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/prims/universalUpcallHandler.cpp ! src/java.base/share/classes/java/lang/Module.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/java/nio/Buffer.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! src/java.base/share/classes/sun/nio/ch/IOUtil.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/AbstractLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Addressable.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/GroupLayout.java - src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAccess.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryHandles.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java - src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayouts.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java + src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/NativeSymbol.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/PaddingLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SequenceLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SymbolLookup.java + src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/VaList.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractCLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LayoutPath.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryAddressImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/NativeSymbolImpl.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/PlatformLayouts.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Scoped.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SystemLookup.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/BufferLayout.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequence.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java - src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/UpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/UpcallStubs.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/TypeClass.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java + src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/TypeClass.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/TypeClass.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/WinVaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java ! test/hotspot/jtreg/gc/shenandoah/compiler/TestLinkToNativeRBP.java ! test/jdk/java/foreign/CallGeneratorHelper.java ! test/jdk/java/foreign/NativeTestHelper.java ! test/jdk/java/foreign/SafeFunctionAccessTest.java ! test/jdk/java/foreign/StdLibTest.java ! test/jdk/java/foreign/TestAdaptVarHandles.java - test/jdk/java/foreign/TestAddressHandle.java + test/jdk/java/foreign/TestArrayCopy.java ! test/jdk/java/foreign/TestArrays.java ! test/jdk/java/foreign/TestByteBuffer.java - test/jdk/java/foreign/TestCircularInit1.java - test/jdk/java/foreign/TestCircularInit2.java ! test/jdk/java/foreign/TestCondy.java ! test/jdk/java/foreign/TestDowncall.java ! test/jdk/java/foreign/TestFree.java ! test/jdk/java/foreign/TestFunctionDescriptor.java ! test/jdk/java/foreign/TestHandshake.java ! test/jdk/java/foreign/TestIllegalLink.java ! test/jdk/java/foreign/TestIntrinsics.java - test/jdk/java/foreign/TestLayoutAttributes.java ! test/jdk/java/foreign/TestLayoutConstants.java ! test/jdk/java/foreign/TestLayoutEquality.java ! test/jdk/java/foreign/TestLayoutPaths.java ! test/jdk/java/foreign/TestLayouts.java ! test/jdk/java/foreign/TestMemoryAccess.java + test/jdk/java/foreign/TestMemoryAccessInstance.java - test/jdk/java/foreign/TestMemoryAccessStatics.java ! test/jdk/java/foreign/TestMemoryAlignment.java - test/jdk/java/foreign/TestMemoryCopy.java + test/jdk/java/foreign/TestMemoryDereference.java ! test/jdk/java/foreign/TestMemoryHandleAsUnsigned.java ! test/jdk/java/foreign/TestMismatch.java ! test/jdk/java/foreign/TestNULLAddress.java ! test/jdk/java/foreign/TestNative.java ! test/jdk/java/foreign/TestNoForeignUnsafeOverride.java ! test/jdk/java/foreign/TestNulls.java - test/jdk/java/foreign/TestRebase.java ! test/jdk/java/foreign/TestReshape.java ! test/jdk/java/foreign/TestResourceScope.java ! test/jdk/java/foreign/TestRestricted.java ! test/jdk/java/foreign/TestScopedOperations.java ! test/jdk/java/foreign/TestSegmentAllocators.java + test/jdk/java/foreign/TestSegmentCopy.java + test/jdk/java/foreign/TestSegmentOffset.java + test/jdk/java/foreign/TestSegmentOverlap.java ! test/jdk/java/foreign/TestSegments.java ! test/jdk/java/foreign/TestSharedAccess.java ! test/jdk/java/foreign/TestSlices.java ! test/jdk/java/foreign/TestSpliterator.java ! test/jdk/java/foreign/TestStringEncoding.java ! test/jdk/java/foreign/TestSymbolLookup.java ! test/jdk/java/foreign/TestTypeAccess.java ! test/jdk/java/foreign/TestUnsupportedPlatform.java ! test/jdk/java/foreign/TestUpcall.java ! test/jdk/java/foreign/TestUpcallException.java ! test/jdk/java/foreign/TestUpcallHighArity.java ! test/jdk/java/foreign/TestUpcallStructScope.java ! test/jdk/java/foreign/TestVarArgs.java ! test/jdk/java/foreign/TestVarHandleCombinators.java ! test/jdk/java/foreign/ThrowingUpcall.java ! test/jdk/java/foreign/callarranger/TestAarch64CallArranger.java ! test/jdk/java/foreign/callarranger/TestWindowsCallArranger.java ! test/jdk/java/foreign/channels/AbstractChannelsTest.java ! test/jdk/java/foreign/channels/TestAsyncSocketChannels.java ! test/jdk/java/foreign/channels/TestSocketChannels.java ! test/jdk/java/foreign/enablenativeaccess/org/openjdk/foreigntest/PanamaMainUnnamedModule.java ! test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/PanamaMain.java ! test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/PanamaMainInvoke.java ! test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/PanamaMainReflection.java ! test/jdk/java/foreign/handles/invoker_module/handle/invoker/MethodHandleInvoker.java ! test/jdk/java/foreign/handles/lookup_module/handle/lookup/MethodHandleLookup.java + test/jdk/java/foreign/libAsyncInvokers.cpp ! test/jdk/java/foreign/libIntrinsics.c ! test/jdk/java/foreign/libSafeAccess.c + test/jdk/java/foreign/loaderLookup/TestLoaderLookup.java + test/jdk/java/foreign/loaderLookup/invoker/Invoker.java + test/jdk/java/foreign/loaderLookup/lookup/Lookup.java + test/jdk/java/foreign/loaderLookup/lookup/libFoo.c ! test/jdk/java/foreign/malloc/TestMixedMallocFree.java ! test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java ! test/jdk/java/foreign/stackwalk/TestStackWalk.java ! test/jdk/java/foreign/valist/VaListTest.java ! test/jdk/java/foreign/virtual/TestVirtualCalls.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java ! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/BulkMismatchAcquire.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/BulkOps.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/CLayouts.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadConstant.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadHelper.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadVirtual.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/JNICB.h + test/micro/org/openjdk/bench/jdk/incubator/foreign/JNICB.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverConstant.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNew.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNewHeap.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstant.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantFP.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantHeap.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantMapped.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantShared.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverPollutedBuffer.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverPollutedSegments.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/ParallelSum.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/QSort.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/StrLenTest.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/TestAdaptVarHandles.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/TestLoadBytes.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/UnrolledAccess.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/Upcalls.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/VaList.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/VarHandleExact.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libCallOverhead.c + test/micro/org/openjdk/bench/jdk/incubator/foreign/libJNICB.c + test/micro/org/openjdk/bench/jdk/incubator/foreign/libQSort.c + test/micro/org/openjdk/bench/jdk/incubator/foreign/libQSortJNI.c ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libUpcallsJNI.c ! test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java ! test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreBytes.java ! test/micro/org/openjdk/bench/jdk/incubator/vector/TestLoadStoreShort.java Changeset: cf7adae6 Author: Thomas Stuefe Date: 2021-11-24 12:12:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf7adae6333c7446048ef0364737927337631f63 8275320: NMT should perform buffer overrun checks 8275320: NMT should perform buffer overrun checks 8275301: Unify C-heap buffer overrun checks into NMT Reviewed-by: simonis, zgu ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/services/mallocSiteTable.cpp ! src/hotspot/share/services/mallocSiteTable.hpp ! src/hotspot/share/services/mallocTracker.cpp ! src/hotspot/share/services/mallocTracker.hpp ! src/hotspot/share/services/memTracker.hpp ! src/hotspot/share/utilities/debug.cpp + test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp ! test/hotspot/gtest/testutils.cpp ! test/hotspot/gtest/testutils.hpp ! test/hotspot/gtest/unittest.hpp Changeset: 0384739a Author: Roger Riggs Date: 2021-11-24 15:14:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0384739afc2d470ab6a3525e9d85aca0af58f2ed 8276665: ObjectInputStream.GetField.get(name, object) should throw ClassNotFoundException Reviewed-by: naoto, lancea, smarks ! src/java.base/share/classes/java/io/ObjectInputStream.java + test/jdk/java/io/Serializable/GetField/ReadFieldsCNF.java Changeset: 663e33de Author: Christian Stein Committer: Jonathan Gibbons Date: 2021-11-24 16:50:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/663e33de13788586fa49bd9816bd148e58ad1031 8272728: javac ignores any -J option in @argfiles silently Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! test/langtools/tools/javac/options/modes/AtFilesTest.java Changeset: 951247c8 Author: Adam Sotona Date: 2021-11-24 17:03:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/951247c8cb4ea898bf7c188bed8e143ca7417c83 8235876: Misleading warning message in java source-file mode Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java ! test/langtools/tools/javac/launcher/SourceLauncherTest.java Changeset: 077b2de0 Author: Andrey Turbanov Committer: Vicente Romero Date: 2021-11-24 18:47:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/077b2de088665b907dbfc2b0522a1e109d1d2ca3 8274161: Cleanup redundant casts in jdk.compiler Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java Changeset: 96fe1d0d Author: Leonid Mesnik Date: 2021-11-24 20:11:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/96fe1d0d4d95d87950ff2ecec570a927d831746e 8264605: vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/TestDescription.java failed with "agent_tools.cpp, 471: (foundThread = (jthread) jni_env->NewGlobalRef(foundThread)) != NULL" Reviewed-by: sspitsyn, dholmes ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_tools.cpp Changeset: e785f699 Author: Pavel Rappo Date: 2021-11-24 20:13:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e785f699614abc8d557be8fc1782a1f86f272430 8276124: Provide snippet support for properties files Co-authored-by: Jonathan Gibbons Co-authored-by: Hannes Walln?fer Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/SnippetTester.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestLangProperties.java Changeset: b5841ba3 Author: Lance Andersen Date: 2021-11-24 20:42:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b5841ba3f3d079f3cfee532a4e7f23b00f5cd063 8277806: 4 tools/jar failures per platform after JDK-8272728 Reviewed-by: alanb, jjg ! test/jdk/tools/jar/modularJar/Basic.java ! test/jdk/tools/jar/multiRelease/MRTestBase.java Changeset: 26472bd3 Author: Daniel D. Daugherty Date: 2021-11-24 22:27:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/26472bd3bd8788b0839e2871ed220e438fb6d608 8277811: ProblemList vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic001/TestDescription.java 8277813: ProblemList vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/TestDescription.java Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList.txt Changeset: a81e4fc0 Author: Jaikiran Pai Date: 2021-11-25 02:12:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a81e4fc07b654a3cc954921981d9d3c0cfd8bcec 8258117: jar tool sets the time stamp of module-info.class entries to the current time Reviewed-by: lancea, ihse, alanb ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java + test/jdk/tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java Changeset: 21e302a0 Author: Daniel D. Daugherty Date: 2021-11-25 04:27:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/21e302a0f4cbf3ace907c36d871a2f2cf6277188 8270435: UT: MonitorUsedDeflationThresholdTest failed: did not find too_many string in output Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/Monitor/MonitorUsedDeflationThresholdTest.java Changeset: f0136ec9 Author: Fairoz Matte Committer: Christian Hagedorn Date: 2021-11-25 08:37:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f0136ec94539d0e30ec11d44f8143196da1f7125 8275687: runtime/CommandLine/PrintTouchedMethods test shouldn't catch RuntimeException Reviewed-by: iklam, chagedorn ! test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethodsJcmd.java Changeset: 3034ae87 Author: Erik ?sterlund Date: 2021-11-25 09:50:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3034ae87ce4b94c7dc40cfb5a96d6d1e87910bbf 8277631: ZGC: CriticalMetaspaceAllocation asserts Reviewed-by: pliden, stefank, dholmes ! src/hotspot/share/memory/metaspaceCriticalAllocation.cpp ! test/hotspot/jtreg/vmTestbase/gc/gctests/LoadUnloadGC/LoadUnloadGC.java Changeset: f7888349 Author: Ivan Walulya Date: 2021-11-25 14:10:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f788834998eeb9083e971857446321ed173aa916 8277786: G1: Rename log2_card_region_per_heap_region used in G1CardSet Reviewed-by: ayang, tschatzl, mli ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp Changeset: 98799204 Author: Albert Mingkun Yang Date: 2021-11-25 14:54:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/987992042454f92936d3efbd01e7beb921e3b70e 8277825: Remove unused ReferenceProcessorPhaseTimes::_sub_phases_total_time_ms Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp ! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.hpp Changeset: eb4d886b Author: Andrey Turbanov Committer: Sergey Bylokhov Date: 2021-11-26 01:45:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb4d886bc0f57085b21ef41f2069ff60b2714cfa 8277504: Use String.stripTrailing instead of hand-crafted method in SwingUtilities2 Reviewed-by: pbansal, serb ! src/java.desktop/share/classes/sun/swing/SwingUtilities2.java Changeset: 7e54d065 Author: Mandy Chung Date: 2021-11-26 01:55:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e54d065a17f1277adf1b8561fadb8a480bc6bed 8277165: jdeps --multi-release --print-module-deps fails if module-info.class in different versioned directories 8277166: Data race in jdeps VersionHelper 8277123: jdeps does not report some exceptions correctly Reviewed-by: jvernee, alanb ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/MultiReleaseException.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/VersionHelper.java + test/langtools/tools/jdeps/multiVersion/MultiVersionError.java + test/langtools/tools/jdeps/multiVersion/src/m1/module-info.java + test/langtools/tools/jdeps/multiVersion/src/m1/p/Test.java + test/langtools/tools/jdeps/multiVersion/src/m1/p/internal/P.java + test/langtools/tools/jdeps/multiVersion/src/m2/module-info.java + test/langtools/tools/jdeps/multiVersion/src/m2/p/internal/P.java + test/langtools/tools/jdeps/multiVersion/src/m2/q/Q.java Changeset: 3383c0dc Author: Stuart Monteith Committer: Nick Gasson Date: 2021-11-26 09:02:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3383c0dcc016715dcb350b6ba196a7cdc833cdc6 8277659: [TESTBUG] Microbenchmark ThreadOnSpinWaitProducerConsumer.java hangs Reviewed-by: njian, ngasson ! test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitProducerConsumer.java Changeset: 00a6238d Author: Yadong Wang Committer: Fei Yang Date: 2021-11-26 09:09:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/00a6238daed4a4aaa6001275ce620646cdabfeb5 8277508: need to check has_predicated_vectors before calling scalable_predicate_reg_slots Reviewed-by: njian, thartmann, ngasson ! src/hotspot/share/opto/matcher.cpp Changeset: 99e4bda3 Author: Roman Kennke Date: 2021-11-26 09:46:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/99e4bda303f2c71972a125d0ecaf4cf986c8614a 8277417: C1 LIR instruction for load-klass Reviewed-by: iveresov, mdoerr, ngasson, aph ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRAssembler.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/gc/shared/c1/barrierSetC1.cpp Changeset: 3e798dd4 Author: Roland Westrelin Date: 2021-11-26 09:48:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3e798dd40c68439f3220445e679b9e0e495435d8 8275330: C2: assert(n->is_Root() || n->is_Region() || n->is_Phi() || n->is_MachMerge() || def_block->dominates(block)) failed: uses must be dominated by definitions Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/opaquenode.cpp ! src/hotspot/share/opto/opaquenode.hpp + test/hotspot/jtreg/compiler/loopopts/TestDeadPostLoopBecausePredicate.java Changeset: 040b2c52 Author: Ludvig Janiuk Committer: Nils Eliasson Date: 2021-11-26 09:52:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/040b2c52d3e82048630fbd45a7db48a5e65204b7 8277139: Improve code readability in PredecessorValidator (c1_IR.cpp) Reviewed-by: thartmann, chagedorn ! src/hotspot/share/c1/c1_IR.cpp Changeset: ddb61725 Author: duke Date: 2021-11-26 11:00:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ddb61725746c50473090ec1467c2c42538691aa7 Automatic merge of jdk:master into master Changeset: ac67414d Author: J. Duke Committer: Maurizio Cimadamore Date: 2021-11-26 14:50:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ac67414d41ac8dc6e59d947a57f45b109b22d78d Merge master ! src/hotspot/share/ci/ciEnv.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java ! test/jdk/java/foreign/TestFunctionDescriptor.java ! test/jdk/java/foreign/TestUpcall.java ! src/hotspot/share/ci/ciEnv.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableUpcallHandler.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java ! test/jdk/java/foreign/TestFunctionDescriptor.java ! test/jdk/java/foreign/TestUpcall.java Changeset: 2c7b5f99 Author: duke Date: 2021-11-26 14:51:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2c7b5f99d2e991720db2bd464b7f8c053ead4c2b Automatic merge of foreign-memaccess+abi into foreign-jextract ! make/conf/jib-profiles.js ! make/conf/jib-profiles.js From mcimadamore at openjdk.java.net Fri Nov 26 15:05:35 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 26 Nov 2021 15:05:35 GMT Subject: [foreign-jextract] RFR: Replace `ofAddressNative` with `ofAddress` Message-ID: The PR for JEP-419 tweaked the name of an API method, namely `MemorySegment.ofAddressNative` which was renamed to `MemorySegment::ofAddress` (which is consistent with other restricted factories). This change updates the jextract code and tests so that the old method name is no longer used. ------------- Commit messages: - Replace `ofAddressNative` with `ofAddress` Changes: https://git.openjdk.java.net/panama-foreign/pull/619/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=619&range=00 Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/619.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/619/head:pull/619 PR: https://git.openjdk.java.net/panama-foreign/pull/619 From jvernee at openjdk.java.net Fri Nov 26 15:05:36 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 26 Nov 2021 15:05:36 GMT Subject: [foreign-jextract] RFR: Replace `ofAddressNative` with `ofAddress` In-Reply-To: References: Message-ID: On Fri, 26 Nov 2021 14:58:08 GMT, Maurizio Cimadamore wrote: > The PR for JEP-419 tweaked the name of an API method, namely `MemorySegment.ofAddressNative` which was renamed to `MemorySegment::ofAddress` (which is consistent with other restricted factories). > > This change updates the jextract code and tests so that the old method name is no longer used. Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/619 From mcimadamore at openjdk.java.net Fri Nov 26 15:09:13 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 26 Nov 2021 15:09:13 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: Replace `ofAddressNative` with `ofAddress` Message-ID: Changeset: 35576e79 Author: Maurizio Cimadamore Date: 2021-11-26 15:08:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35576e794693bb546c8c05383296f2edd06dcb4c Replace `ofAddressNative` with `ofAddress` Reviewed-by: jvernee ! src/jdk.incubator.jextract/share/classes/jdk/internal/clang/TranslationUnit.java ! src/jdk.incubator.jextract/share/classes/jdk/internal/clang/libclang/RuntimeHelper.java ! src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/resources/RuntimeHelper.java.template ! test/jdk/tools/jextract/test8246341/LibTest8246341Test.java ! test/jdk/tools/jextract/test8257892/LibUnsupportedTest.java From mcimadamore at openjdk.java.net Fri Nov 26 15:12:24 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 26 Nov 2021 15:12:24 GMT Subject: [foreign-jextract] Integrated: Replace `ofAddressNative` with `ofAddress` In-Reply-To: References: Message-ID: On Fri, 26 Nov 2021 14:58:08 GMT, Maurizio Cimadamore wrote: > The PR for JEP-419 tweaked the name of an API method, namely `MemorySegment.ofAddressNative` which was renamed to `MemorySegment::ofAddress` (which is consistent with other restricted factories). > > This change updates the jextract code and tests so that the old method name is no longer used. This pull request has now been integrated. Changeset: 35576e79 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/35576e794693bb546c8c05383296f2edd06dcb4c Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod Replace `ofAddressNative` with `ofAddress` Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/619 From youngty1997 at gmail.com Sat Nov 27 01:17:35 2021 From: youngty1997 at gmail.com (Ty Young) Date: Fri, 26 Nov 2021 19:17:35 -0600 Subject: Java value layout constants In-Reply-To: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> References: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> Message-ID: Sorry for the late reply, busy with thanksgiving. This seems to be exactly what I personally wanted. Looking at the exact code, I feel like most if not all of the if-else and other checks in places like MemoryAddress getAtIndex could be eliminated if the API was arranged differently. Specifically, if ValueLayout was an interface with a non-exported, internal implementation, maybe MethodHandles could then be used to point to the correct branches directly by a one-time switch when the bit alignment is modified. The MethodHandles could then be retrieved via the non-exported, internal implementation via a type cast. Maybe that makes the performance worse, I haven't tried it. I just figured it would look cleaner. Again, it seems to be what I wanted so +1 from me for what it's worth. On 11/25/21 9:52 AM, Maurizio Cimadamore wrote: > Hi, > This is a followup of the disccussion that started in [1]. In the new > changes slated for Java 18, the set of Java value layout constants are > all byte-aligned (e.g. alignment constraints are not set). The > motivation for this is mostly historical (but there's also a > performance twist, see below): the dereference primitives in > MemoryAccess used to setup var handles based on non-aligned layouts. > So, to preserve compatibility with what we had before, we opted to > "relax" alignment constraints on the JAVA_XYZ layout constants in > ValueLayout. During the development of the new dereference API, some > issues arised around alignment checks and memory copy [2]; which also > contributed to consolidate the feeling that Java layout constants > should be unaligned. > > Now, while it's always possible, for clients, to go back to the > desired alignment constraints (e.g. by defining custom layout > constants), from the discussion it emerged that it can be somewhat > confusing/surprising having a layout constant called JAVA_INT, whose > alignment is not the VM alignment for a Java int value. > > For this reason, I'd like to propose a small tweak, which would > essentially revert alignment constraints for Java layout constants to > what they were in 17. In other words, let's keep the "good" JAVA_XYZ > names for the _true_ Java layouts (including alignment as seen by VM). > If clients want to create unaligned constants they can do so, as they > can also create big-endian constants where needed. In the majority of > cases, since access will be aligned (for performance reasons), this > will not really change much for clients. But some of those clients > that need to pack data structures more (Lucene?) will need to define > their own packed/unaligned layout constants. > > Does that seem like an acceptable compromise? > > A patch for these changes is available here: > > https://github.com/mcimadamore/jdk/tree/value_layout_align > > While testing it, I was reminded (once more) that access with > alignment constraints is currently slower than access w/o alignment > constraints - which has to do with C2 not hoisting alignment checks in > cases like this: > > ((segmentBaseAddress + accessedOffset) & alignmentMask) == 0 > > Here, segmentBaseAddress is a loop invariant, and the accessedOffset > depends on the loop variable. So, it is in principle possible for the > VM to hoist the check for baseAddress and to eliminate the alignment > check for the offset (which would come from BCE analysis). But this is > not how things work today. The patch works around this, by using > different var handles for when the accessed offset is provably aligned > (e.g. when using the getAtIndex/setAtIndex APIs). Even with those > workarounds, calling getAtIndex/setAtIndex on a MemoryAddress is still > slower than on a MemorySegment, because of the way in which we try to > workaround the long loop optimization problem. Luckily a fix for that > problem [3] has been integrated in JDK 18, which means we will remove > these implementation workaround, which will help making performance > more stable across the board. > > If the changes in this patch seem good, I'm happy to try and integrate > this into 18. > > Cheers > Maurizio > > [1] - > https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015805.html > [2] - > https://github.com/openjdk/panama-foreign/pull/555#issuecomment-865115787 > [3] - https://github.com/openjdk/jdk/pull/2045 > > > From uschindler at apache.org Sat Nov 27 10:00:49 2021 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 27 Nov 2021 11:00:49 +0100 Subject: Java value layout constants In-Reply-To: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> References: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> Message-ID: <049701d7e375$a8813dc0$f983b940$@apache.org> Hi Maurizio, > For this reason, I'd like to propose a small tweak, which would > essentially revert alignment constraints for Java layout constants to > what they were in 17. In other words, let's keep the "good" JAVA_XYZ > names for the _true_ Java layouts (including alignment as seen by VM). > If clients want to create unaligned constants they can do so, as they > can also create big-endian constants where needed. In the majority of > cases, since access will be aligned (for performance reasons), this will > not really change much for clients. But some of those clients that need > to pack data structures more (Lucene?) will need to define their own > packed/unaligned layout constants. That's all fine. In my first JDK 18 branch of Lucene's new MMapDirectory, I did it like that: https://github.com/uschindler/lucene/blob/ad3a81e3d348d6aa417aa785bdfe9e7a39c1ee53/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java#L36-L40 Basically we have layout constants anyways (as the file format has a defined byte order). At the time when I wrote this (in September) I was already thinking: "maybe add withBitAlignment(8) everywhere?" In general, when you define your own constant for on-disk layouts it is always adviseable to be specifc with byte order and alignment. Anyway, we are working on Lucene to have alignment in our files at least for those non-packed formats. E.g. we now align file slices (we call them CFS files) always with 8 bytes to not add additional misalignment there. At some point in future we may to enable the alignment checks, but this will be after several years (file format compatibility). Uwe From uschindler at apache.org Sat Nov 27 14:24:15 2021 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 27 Nov 2021 14:24:15 +0000 Subject: Java value layout constants In-Reply-To: References: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> <049701d7e375$a8813dc0$f983b940$@apache.org> Message-ID: Hi, File formats in Lucene were always big endian (all currently released versions). With soon to be released 9.0 files we changed to little endian. We did the change in 9.0 due to the fact that most platforms are little endian. For reading older index files (e.g. from mixed indexes, some segments old others new, the backwards compatibility codecs wrap a endian switching wrapper on top of all index inputs. This slows reading old indexes due to extra method calls (this is also the reason why the panama directory impl can't be used with old Lucene versions, so it's a backwards incompatible change of API definition) There is no plans (and won't ever be) to make endianness platform dependent. Maintenance is too hard. We just use the most common one. Uwe Am 27. November 2021 14:04:12 UTC schrieb Rado Smogura : >Hi Uwe, > > >I've got just one thing, more about Lucene (I guess it was already >thought through). In this code you specify the byte order. I guess >overall performance could be better if all things will be in native >order, unless there's requirement Lucene files to be cross-platform >copyable (I know Lucene only from it's wrapper ES). > > >BR, > >Rado > >On 27.11.2021 11:00, Uwe Schindler wrote: >> Hi Maurizio, >> >>> For this reason, I'd like to propose a small tweak, which would >>> essentially revert alignment constraints for Java layout constants to >>> what they were in 17. In other words, let's keep the "good" JAVA_XYZ >>> names for the _true_ Java layouts (including alignment as seen by VM). >>> If clients want to create unaligned constants they can do so, as they >>> can also create big-endian constants where needed. In the majority of >>> cases, since access will be aligned (for performance reasons), this will >>> not really change much for clients. But some of those clients that need >>> to pack data structures more (Lucene?) will need to define their own >>> packed/unaligned layout constants. >> That's all fine. In my first JDK 18 branch of Lucene's new MMapDirectory, I did it like that: >> https://github.com/uschindler/lucene/blob/ad3a81e3d348d6aa417aa785bdfe9e7a39c1ee53/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java#L36-L40 >> >> Basically we have layout constants anyways (as the file format has a defined byte order). At the time when I wrote this (in September) I was already thinking: "maybe add withBitAlignment(8) everywhere?" >> >> In general, when you define your own constant for on-disk layouts it is always adviseable to be specifc with byte order and alignment. >> >> Anyway, we are working on Lucene to have alignment in our files at least for those non-packed formats. E.g. we now align file slices (we call them CFS files) always with 8 bytes to not add additional misalignment there. At some point in future we may to enable the alignment checks, but this will be after several years (file format compatibility). >> >> Uwe >> -- Uwe Schindler Achterdiek 19, 28357 Bremen https://www.thetaphi.de From maurizio.cimadamore at oracle.com Mon Nov 29 10:46:00 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 29 Nov 2021 10:46:00 +0000 Subject: Java value layout constants In-Reply-To: References: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> Message-ID: On 27/11/2021 01:17, Ty Young wrote: > Sorry for the late reply, busy with thanksgiving. > > > This seems to be exactly what I personally wanted. Looking at the > exact code, I feel like most if not all of the if-else and other > checks in places like MemoryAddress getAtIndex could be eliminated if > the API was arranged differently. Specifically, if ValueLayout was an > interface with a non-exported, internal implementation, maybe > MethodHandles could then be used to point to the correct branches > directly by a one-time switch when the bit alignment is modified. The > MethodHandles could then be retrieved via the non-exported, internal > implementation via a type cast. Maybe that makes the performance > worse, I haven't tried it. I just figured it would look cleaner. There are few issues here to unpack. Historically, memory layouts did not have a "private" API, which is why we did not have an interface + non-exported impl setup. Now, MemoryLayout::accessHandle changes that a bit, so yes, there might be a case that at least some layout impl classes might move in the internal package. That said, some other factors are making this worse: 1. We are essentially working around a VM issue with optimization of alignment checks in loop [1]. Hopefully, that issue will be fixed, and when that happens, we can probably get rid of the special casing. 2. The accessors on MemoryAddress are caller-sensitive, so it is better to put them in an implementation class, and mark them as final (as overriding and caller-sensitive doesn't work). These constraints, moved the impl in the way it is in the branch. I agree that, moving forward (e.g. as we reshuffle APIs around into java.base), it would be good to consider again the choice as to whether memory layouts need to be interface with private impl or not. Maurizio [1] - https://bugs.openjdk.java.net/browse/JDK-8277850 > > > Again, it seems to be what I wanted so +1 from me for what it's worth. > > > On 11/25/21 9:52 AM, Maurizio Cimadamore wrote: >> Hi, >> This is a followup of the disccussion that started in [1]. In the new >> changes slated for Java 18, the set of Java value layout constants >> are all byte-aligned (e.g. alignment constraints are not set). The >> motivation for this is mostly historical (but there's also a >> performance twist, see below): the dereference primitives in >> MemoryAccess used to setup var handles based on non-aligned layouts. >> So, to preserve compatibility with what we had before, we opted to >> "relax" alignment constraints on the JAVA_XYZ layout constants in >> ValueLayout. During the development of the new dereference API, some >> issues arised around alignment checks and memory copy [2]; which also >> contributed to consolidate the feeling that Java layout constants >> should be unaligned. >> >> Now, while it's always possible, for clients, to go back to the >> desired alignment constraints (e.g. by defining custom layout >> constants), from the discussion it emerged that it can be somewhat >> confusing/surprising having a layout constant called JAVA_INT, whose >> alignment is not the VM alignment for a Java int value. >> >> For this reason, I'd like to propose a small tweak, which would >> essentially revert alignment constraints for Java layout constants to >> what they were in 17. In other words, let's keep the "good" JAVA_XYZ >> names for the _true_ Java layouts (including alignment as seen by >> VM). If clients want to create unaligned constants they can do so, as >> they can also create big-endian constants where needed. In the >> majority of cases, since access will be aligned (for performance >> reasons), this will not really change much for clients. But some of >> those clients that need to pack data structures more (Lucene?) will >> need to define their own packed/unaligned layout constants. >> >> Does that seem like an acceptable compromise? >> >> A patch for these changes is available here: >> >> https://github.com/mcimadamore/jdk/tree/value_layout_align >> >> While testing it, I was reminded (once more) that access with >> alignment constraints is currently slower than access w/o alignment >> constraints - which has to do with C2 not hoisting alignment checks >> in cases like this: >> >> ((segmentBaseAddress + accessedOffset) & alignmentMask) == 0 >> >> Here, segmentBaseAddress is a loop invariant, and the accessedOffset >> depends on the loop variable. So, it is in principle possible for the >> VM to hoist the check for baseAddress and to eliminate the alignment >> check for the offset (which would come from BCE analysis). But this >> is not how things work today. The patch works around this, by using >> different var handles for when the accessed offset is provably >> aligned (e.g. when using the getAtIndex/setAtIndex APIs). Even with >> those workarounds, calling getAtIndex/setAtIndex on a MemoryAddress >> is still slower than on a MemorySegment, because of the way in which >> we try to workaround the long loop optimization problem. Luckily a >> fix for that problem [3] has been integrated in JDK 18, which means >> we will remove these implementation workaround, which will help >> making performance more stable across the board. >> >> If the changes in this patch seem good, I'm happy to try and >> integrate this into 18. >> >> Cheers >> Maurizio >> >> [1] - >> https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015805.html >> [2] - >> https://github.com/openjdk/panama-foreign/pull/555#issuecomment-865115787 >> [3] - https://github.com/openjdk/jdk/pull/2045 >> >> >> From maurizio.cimadamore at oracle.com Mon Nov 29 11:09:52 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 29 Nov 2021 11:09:52 +0000 Subject: Java value layout constants In-Reply-To: <049701d7e375$a8813dc0$f983b940$@apache.org> References: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> <049701d7e375$a8813dc0$f983b940$@apache.org> Message-ID: <7f91c96f-b64c-966e-f0fc-1dbc44bdfdfa@oracle.com> Thanks for the feedback. To be clear, the proposed patch should not change the performance charateristics of your application, as long as clients adopts one of the two strategies below: * manually declare a set of unaligned layouts, and use them for dereference (as seems to be the case for Lucene) * always use get/setAtIndex - in which case we can dynamically infer whether the offset is always a multiple of the alignment, and omit the problematic check on the var handle side (we use a similar trick when constructing var handles from layout paths) When 8277850 is fixed, then accessing at index and at offset should have same performance regardless of alignment. Cheers Maurizio On 27/11/2021 10:00, Uwe Schindler wrote: > Hi Maurizio, > >> For this reason, I'd like to propose a small tweak, which would >> essentially revert alignment constraints for Java layout constants to >> what they were in 17. In other words, let's keep the "good" JAVA_XYZ >> names for the _true_ Java layouts (including alignment as seen by VM). >> If clients want to create unaligned constants they can do so, as they >> can also create big-endian constants where needed. In the majority of >> cases, since access will be aligned (for performance reasons), this will >> not really change much for clients. But some of those clients that need >> to pack data structures more (Lucene?) will need to define their own >> packed/unaligned layout constants. > That's all fine. In my first JDK 18 branch of Lucene's new MMapDirectory, I did it like that: > https://urldefense.com/v3/__https://github.com/uschindler/lucene/blob/ad3a81e3d348d6aa417aa785bdfe9e7a39c1ee53/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java*L36-L40__;Iw!!ACWV5N9M2RV99hQ!fLIcQ7APXm6JbsHKLk9PFBi_YpF84eBNehTaedMyHoBVTKVJjYlFItYeVI2Y6-sg9wyaeVo$ > > Basically we have layout constants anyways (as the file format has a defined byte order). At the time when I wrote this (in September) I was already thinking: "maybe add withBitAlignment(8) everywhere?" > > In general, when you define your own constant for on-disk layouts it is always adviseable to be specifc with byte order and alignment. > > Anyway, we are working on Lucene to have alignment in our files at least for those non-packed formats. E.g. we now align file slices (we call them CFS files) always with 8 bytes to not add additional misalignment there. At some point in future we may to enable the alignment checks, but this will be after several years (file format compatibility). > > Uwe > From mcimadamore at openjdk.java.net Mon Nov 29 14:15:49 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 29 Nov 2021 14:15:49 GMT Subject: [foreign-jextract] RFR: 8277830: jextract generated code should not depend on Java layouts Message-ID: This patch tweaks jextract generation, so that a new constant class is emitted, namely `Constant$root`, which contains the definition of all basic C primitive types. These are declared with the correct alignment constraints, depending on platforms. Every other layout created by jextract will depend on these shared layouts constants, so that jextract code doesn't depend on alignment choices in `ValueLayout` constants. In the future, we should probably generalize this approach, so that e.g. layouts are emitted only once, and then referred to afterwards - not just for primitive types, but also for everything else (struct, typedef, etc.). This would minimize the amount of layouts we store in the constant classes. ------------- Commit messages: - Declare primitive layout constants with sharp type, to avoid downstream casts - Cleanup code - Merge branch 'foreign-jextract' into primitive_layouts_jextract - Use C layouts in all constant classes. Changes: https://git.openjdk.java.net/panama-foreign/pull/620/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=620&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277830 Stats: 148 lines in 8 files changed: 90 ins; 37 del; 21 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/620.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/620/head:pull/620 PR: https://git.openjdk.java.net/panama-foreign/pull/620 From mcimadamore at openjdk.java.net Mon Nov 29 14:15:49 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 29 Nov 2021 14:15:49 GMT Subject: [foreign-jextract] RFR: 8277830: jextract generated code should not depend on Java layouts In-Reply-To: References: Message-ID: On Mon, 29 Nov 2021 14:09:29 GMT, Maurizio Cimadamore wrote: > This patch tweaks jextract generation, so that a new constant class is emitted, namely `Constant$root`, which contains the definition of all basic C primitive types. These are declared with the correct alignment constraints, depending on platforms. > > Every other layout created by jextract will depend on these shared layouts constants, so that jextract code doesn't depend on alignment choices in `ValueLayout` constants. > > In the future, we should probably generalize this approach, so that e.g. layouts are emitted only once, and then referred to afterwards - not just for primitive types, but also for everything else (struct, typedef, etc.). This would minimize the amount of layouts we store in the constant classes. I've tested this on some samples I have on Linux - would probably be wise to also test on Windows/Mac. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/620 From uschindler at apache.org Mon Nov 29 14:37:02 2021 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 29 Nov 2021 15:37:02 +0100 Subject: Java value layout constants In-Reply-To: <7f91c96f-b64c-966e-f0fc-1dbc44bdfdfa@oracle.com> References: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> <049701d7e375$a8813dc0$f983b940$@apache.org> <7f91c96f-b64c-966e-f0fc-1dbc44bdfdfa@oracle.com> Message-ID: <055b01d7e52e$939fd1e0$badf75a0$@apache.org> Hi, when you set the alignment to 8 (bits) the alignmentBytes gets 1 and the mask therefore is 0 in the resulting VarHandle. What would be interesting for Lucene: Is the alignment check then always removed by Hotspot (also outside loops)? Because "address & 0" always returns 0 for any address and can easily detected for any code path by Hotspot (e.g., outside loops). I am asking this to make sure that setting the alignment explicit to 8 bits will disable the check completely, in any code path to get optimal performance. For the understanding about this issue: The alignment was disabled but should be enabled again. Why is this so important? If anybody wants to make sure the alignment is ok, why not opt-in? The only problem is atomic accesses then, but for that they VarHandle has the VM_ALIGN extra check, so doing getVolatile() on unaligned address always fails. One last thing I noticed in your branch: Why this complexity?: @Stable private final VarHandle[] handles = new VarHandle[2]; static final int ALIGNED_POS = 0; static final int UNALIGNED_POS = 1; @ForceInline VarHandle accessHandle(boolean aligned) { int pos = aligned ? ALIGNED_POS : UNALIGNED_POS; if (handles[pos] == null) { // this store to stable field is safe, because return value of 'makeMemoryAccessVarHandle' has stable identity handles[pos] = Utils.makeMemoryAccessVarHandle(this, aligned); } return handles[pos]; } Wouldn't it be easier to have 2 varhandle fields: alignedHandle, unalignedHandle in two different @Stable? I am also not a fan of methods taking a boolean and return only 2 different values. I would have 2 methods with only the caching conditional: accesHandleUnaligned() and accessHandleAligned(). This would make code using this more readable. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr Bremen, Germany https://lucene.apache.org/ https://solr.apache.org/ > -----Original Message----- > From: Maurizio Cimadamore > Sent: Monday, November 29, 2021 12:10 PM > To: Uwe Schindler ; panama-dev at openjdk.java.net > Subject: Re: Java value layout constants > > Thanks for the feedback. > > To be clear, the proposed patch should not change the performance > charateristics of your application, as long as clients adopts one of the > two strategies below: > > * manually declare a set of unaligned layouts, and use them for > dereference (as seems to be the case for Lucene) > * always use get/setAtIndex - in which case we can dynamically infer > whether the offset is always a multiple of the alignment, and omit the > problematic check on the var handle side (we use a similar trick when > constructing var handles from layout paths) > > When 8277850 is fixed, then accessing at index and at offset should have > same performance regardless of alignment. > > Cheers > Maurizio > > > On 27/11/2021 10:00, Uwe Schindler wrote: > > Hi Maurizio, > > > >> For this reason, I'd like to propose a small tweak, which would > >> essentially revert alignment constraints for Java layout constants to > >> what they were in 17. In other words, let's keep the "good" JAVA_XYZ > >> names for the _true_ Java layouts (including alignment as seen by VM). > >> If clients want to create unaligned constants they can do so, as they > >> can also create big-endian constants where needed. In the majority of > >> cases, since access will be aligned (for performance reasons), this will > >> not really change much for clients. But some of those clients that need > >> to pack data structures more (Lucene?) will need to define their own > >> packed/unaligned layout constants. > > That's all fine. In my first JDK 18 branch of Lucene's new MMapDirectory, I did > it like that: > > > https://urldefense.com/v3/__https://github.com/uschindler/lucene/blob/ad3a > 81e3d348d6aa417aa785bdfe9e7a39c1ee53/lucene/core/src/java/org/apache/l > ucene/store/MemorySegmentIndexInput.java*L36- > L40__;Iw!!ACWV5N9M2RV99hQ!fLIcQ7APXm6JbsHKLk9PFBi_YpF84eBNehTaed > MyHoBVTKVJjYlFItYeVI2Y6-sg9wyaeVo$ > > > > Basically we have layout constants anyways (as the file format has a defined > byte order). At the time when I wrote this (in September) I was already > thinking: "maybe add withBitAlignment(8) everywhere?" > > > > In general, when you define your own constant for on-disk layouts it is always > adviseable to be specifc with byte order and alignment. > > > > Anyway, we are working on Lucene to have alignment in our files at least for > those non-packed formats. E.g. we now align file slices (we call them CFS files) > always with 8 bytes to not add additional misalignment there. At some point in > future we may to enable the alignment checks, but this will be after several > years (file format compatibility). > > > > Uwe > > From maurizio.cimadamore at oracle.com Mon Nov 29 14:46:46 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 29 Nov 2021 14:46:46 +0000 Subject: Java value layout constants In-Reply-To: <055b01d7e52e$939fd1e0$badf75a0$@apache.org> References: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> <049701d7e375$a8813dc0$f983b940$@apache.org> <7f91c96f-b64c-966e-f0fc-1dbc44bdfdfa@oracle.com> <055b01d7e52e$939fd1e0$badf75a0$@apache.org> Message-ID: On 29/11/2021 14:37, Uwe Schindler wrote: > Hi, > > when you set the alignment to 8 (bits) the alignmentBytes gets 1 and the mask therefore is 0 in the resulting VarHandle. What would be interesting for Lucene: Is the alignment check then always removed by Hotspot (also outside loops)? Because "address & 0" always returns 0 for any address and can easily detected for any code path by Hotspot (e.g., outside loops). I am asking this to make sure that setting the alignment explicit to 8 bits will disable the check completely, in any code path to get optimal performance. This is already how things work - if alignment is set to 8 bits, no alignment check occurs - everything is hoisted. > > For the understanding about this issue: The alignment was disabled but should be enabled again. Why is this so important? If anybody wants to make sure the alignment is ok, why not opt-in? The only problem is atomic accesses then, but for that they VarHandle has the VM_ALIGN extra check, so doing getVolatile() on unaligned address always fails. I think the issue is mostly pedagogical: we have constants called: JAVA_INT, JAVA_LONG, and so forth - but they don't have the alignment the JVM thinks they have, and that can be surprising, coming from an official Java SE API. Plus, if the default is unaligned, there might be odd exceptions when accessing unaligned memory locations on platforms which do not support such unaligned access. In other words, of the two (aligned vs. unaligned), the case for having constants track "official" alignment constraints of Java primitive types seems stronger. > > One last thing I noticed in your branch: Why this complexity?: > > @Stable > private final VarHandle[] handles = new VarHandle[2]; > > static final int ALIGNED_POS = 0; > static final int UNALIGNED_POS = 1; > > @ForceInline > VarHandle accessHandle(boolean aligned) { > int pos = aligned ? ALIGNED_POS : UNALIGNED_POS; > if (handles[pos] == null) { > // this store to stable field is safe, because return value of 'makeMemoryAccessVarHandle' has stable identity > handles[pos] = Utils.makeMemoryAccessVarHandle(this, aligned); > } > return handles[pos]; > } > > Wouldn't it be easier to have 2 varhandle fields: alignedHandle, unalignedHandle in two different @Stable? We can easily tweak this. But the two var handles are required to workaround the performance penalties around JDK-8277850. Maurizio > > I am also not a fan of methods taking a boolean and return only 2 different values. I would have 2 methods with only the caching conditional: accesHandleUnaligned() and accessHandleAligned(). This would make code using this more readable. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr > Bremen, Germany > https://urldefense.com/v3/__https://lucene.apache.org/__;!!ACWV5N9M2RV99hQ!a-C8rUhoRuAlURlp8Ljs8B52jMflRmzAumz_Vpil8bdTa6J_pxDh0chcqO8FLlUh4XYAwf4$ > https://urldefense.com/v3/__https://solr.apache.org/__;!!ACWV5N9M2RV99hQ!a-C8rUhoRuAlURlp8Ljs8B52jMflRmzAumz_Vpil8bdTa6J_pxDh0chcqO8FLlUhuv6vUTw$ > >> -----Original Message----- >> From: Maurizio Cimadamore >> Sent: Monday, November 29, 2021 12:10 PM >> To: Uwe Schindler ; panama-dev at openjdk.java.net >> Subject: Re: Java value layout constants >> >> Thanks for the feedback. >> >> To be clear, the proposed patch should not change the performance >> charateristics of your application, as long as clients adopts one of the >> two strategies below: >> >> * manually declare a set of unaligned layouts, and use them for >> dereference (as seems to be the case for Lucene) >> * always use get/setAtIndex - in which case we can dynamically infer >> whether the offset is always a multiple of the alignment, and omit the >> problematic check on the var handle side (we use a similar trick when >> constructing var handles from layout paths) >> >> When 8277850 is fixed, then accessing at index and at offset should have >> same performance regardless of alignment. >> >> Cheers >> Maurizio >> >> >> On 27/11/2021 10:00, Uwe Schindler wrote: >>> Hi Maurizio, >>> >>>> For this reason, I'd like to propose a small tweak, which would >>>> essentially revert alignment constraints for Java layout constants to >>>> what they were in 17. In other words, let's keep the "good" JAVA_XYZ >>>> names for the _true_ Java layouts (including alignment as seen by VM). >>>> If clients want to create unaligned constants they can do so, as they >>>> can also create big-endian constants where needed. In the majority of >>>> cases, since access will be aligned (for performance reasons), this will >>>> not really change much for clients. But some of those clients that need >>>> to pack data structures more (Lucene?) will need to define their own >>>> packed/unaligned layout constants. >>> That's all fine. In my first JDK 18 branch of Lucene's new MMapDirectory, I did >> it like that: >> https://urldefense.com/v3/__https://github.com/uschindler/lucene/blob/ad3a >> 81e3d348d6aa417aa785bdfe9e7a39c1ee53/lucene/core/src/java/org/apache/l >> ucene/store/MemorySegmentIndexInput.java*L36- >> L40__;Iw!!ACWV5N9M2RV99hQ!fLIcQ7APXm6JbsHKLk9PFBi_YpF84eBNehTaed >> MyHoBVTKVJjYlFItYeVI2Y6-sg9wyaeVo$ >>> Basically we have layout constants anyways (as the file format has a defined >> byte order). At the time when I wrote this (in September) I was already >> thinking: "maybe add withBitAlignment(8) everywhere?" >>> In general, when you define your own constant for on-disk layouts it is always >> adviseable to be specifc with byte order and alignment. >>> Anyway, we are working on Lucene to have alignment in our files at least for >> those non-packed formats. E.g. we now align file slices (we call them CFS files) >> always with 8 bytes to not add additional misalignment there. At some point in >> future we may to enable the alignment checks, but this will be after several >> years (file format compatibility). >>> Uwe >>> From maurizio.cimadamore at oracle.com Mon Nov 29 14:58:15 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 29 Nov 2021 14:58:15 +0000 Subject: Java value layout constants In-Reply-To: References: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> <049701d7e375$a8813dc0$f983b940$@apache.org> <7f91c96f-b64c-966e-f0fc-1dbc44bdfdfa@oracle.com> <055b01d7e52e$939fd1e0$badf75a0$@apache.org> Message-ID: On 29/11/2021 14:46, Maurizio Cimadamore wrote: > We can easily tweak this. But the two var handles are required to > workaround the performance penalties around JDK-8277850. Also note that usages like these: https://github.com/mcimadamore/jdk/blob/value_layout_align/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java#L1443 Won't be too happy if we had two different methods. Maurizio From sundar at openjdk.java.net Mon Nov 29 15:28:26 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 29 Nov 2021 15:28:26 GMT Subject: [foreign-jextract] RFR: 8277830: jextract generated code should not depend on Java layouts In-Reply-To: References: Message-ID: <2WOhc1H3kN6HTPRR2YMTnzTVbV0WIbH0UkO31Y-aRK4=.b18957c3-3cee-47d7-8dfd-98324463467a@github.com> On Mon, 29 Nov 2021 14:09:29 GMT, Maurizio Cimadamore wrote: > This patch tweaks jextract generation, so that a new constant class is emitted, namely `Constant$root`, which contains the definition of all basic C primitive types. These are declared with the correct alignment constraints, depending on platforms. > > Every other layout created by jextract will depend on these shared layouts constants, so that jextract code doesn't depend on alignment choices in `ValueLayout` constants. > > In the future, we should probably generalize this approach, so that e.g. layouts are emitted only once, and then referred to afterwards - not just for primitive types, but also for everything else (struct, typedef, etc.). This would minimize the amount of layouts we store in the constant classes. approved. build/test fine on Mac. samples run fine on Mac as well ------------- Marked as reviewed by sundar (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/620 From jvernee at openjdk.java.net Mon Nov 29 15:42:25 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 29 Nov 2021 15:42:25 GMT Subject: [foreign-jextract] RFR: 8277830: jextract generated code should not depend on Java layouts In-Reply-To: References: Message-ID: On Mon, 29 Nov 2021 14:09:29 GMT, Maurizio Cimadamore wrote: > This patch tweaks jextract generation, so that a new constant class is emitted, namely `Constant$root`, which contains the definition of all basic C primitive types. These are declared with the correct alignment constraints, depending on platforms. > > Every other layout created by jextract will depend on these shared layouts constants, so that jextract code doesn't depend on alignment choices in `ValueLayout` constants. > > In the future, we should probably generalize this approach, so that e.g. layouts are emitted only once, and then referred to afterwards - not just for primitive types, but also for everything else (struct, typedef, etc.). This would minimize the amount of layouts we store in the constant classes. src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/ToplevelBuilder.java line 245: > 243: return "JAVA_CHAR.withBitAlignment(" + vl.bitAlignment() + ")"; > 244: } else if (vl.carrier() == byte.class) { > 245: return "JAVA_BYTE"; What about hyper-aligned bytes and booleans? Don't we always need a call to `withBitAlignment` ? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/620 From jvernee at openjdk.java.net Mon Nov 29 15:47:28 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 29 Nov 2021 15:47:28 GMT Subject: [foreign-jextract] RFR: 8277830: jextract generated code should not depend on Java layouts In-Reply-To: References: Message-ID: On Mon, 29 Nov 2021 14:58:28 GMT, Jorn Vernee wrote: >> This patch tweaks jextract generation, so that a new constant class is emitted, namely `Constant$root`, which contains the definition of all basic C primitive types. These are declared with the correct alignment constraints, depending on platforms. >> >> Every other layout created by jextract will depend on these shared layouts constants, so that jextract code doesn't depend on alignment choices in `ValueLayout` constants. >> >> In the future, we should probably generalize this approach, so that e.g. layouts are emitted only once, and then referred to afterwards - not just for primitive types, but also for everything else (struct, typedef, etc.). This would minimize the amount of layouts we store in the constant classes. > > src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/ToplevelBuilder.java line 245: > >> 243: return "JAVA_CHAR.withBitAlignment(" + vl.bitAlignment() + ")"; >> 244: } else if (vl.carrier() == byte.class) { >> 245: return "JAVA_BYTE"; > > What about hyper-aligned bytes and booleans? Don't we always need a call to `withBitAlignment` ? Ah I guess this code is only called from the methods below. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/620 From mcimadamore at openjdk.java.net Mon Nov 29 15:57:21 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 29 Nov 2021 15:57:21 GMT Subject: [foreign-jextract] RFR: 8277830: jextract generated code should not depend on Java layouts In-Reply-To: References: Message-ID: <1-2rSehrtwst4NpBDe3zTh-m7UJALR6wb4r4eE9C27w=.b6c03bdb-01f3-4792-81a6-ac2d8e4c22f4@github.com> On Mon, 29 Nov 2021 15:44:32 GMT, Jorn Vernee wrote: >> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/ToplevelBuilder.java line 245: >> >>> 243: return "JAVA_CHAR.withBitAlignment(" + vl.bitAlignment() + ")"; >>> 244: } else if (vl.carrier() == byte.class) { >>> 245: return "JAVA_BYTE"; >> >> What about hyper-aligned bytes and booleans? Don't we always need a call to `withBitAlignment` ? > > Ah I guess this code is only called from the methods below. yeah - this is just for the primitive layout that get added "by default". ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/620 From mcimadamore at openjdk.java.net Mon Nov 29 15:57:21 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 29 Nov 2021 15:57:21 GMT Subject: [foreign-jextract] RFR: 8277830: jextract generated code should not depend on Java layouts In-Reply-To: <1-2rSehrtwst4NpBDe3zTh-m7UJALR6wb4r4eE9C27w=.b6c03bdb-01f3-4792-81a6-ac2d8e4c22f4@github.com> References: <1-2rSehrtwst4NpBDe3zTh-m7UJALR6wb4r4eE9C27w=.b6c03bdb-01f3-4792-81a6-ac2d8e4c22f4@github.com> Message-ID: On Mon, 29 Nov 2021 15:53:30 GMT, Maurizio Cimadamore wrote: >> Ah I guess this code is only called from the methods below. > > yeah - this is just for the primitive layout that get added "by default". Note also that we do not really have a way to deal with hyper (or under) aligned types (e.g. pragma pack). See: https://bugs.openjdk.java.net/browse/JDK-8259832 ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/620 From jvernee at openjdk.java.net Mon Nov 29 16:07:21 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 29 Nov 2021 16:07:21 GMT Subject: [foreign-jextract] RFR: 8277830: jextract generated code should not depend on Java layouts In-Reply-To: References: Message-ID: On Mon, 29 Nov 2021 14:09:29 GMT, Maurizio Cimadamore wrote: > This patch tweaks jextract generation, so that a new constant class is emitted, namely `Constant$root`, which contains the definition of all basic C primitive types. These are declared with the correct alignment constraints, depending on platforms. > > Every other layout created by jextract will depend on these shared layouts constants, so that jextract code doesn't depend on alignment choices in `ValueLayout` constants. > > In the future, we should probably generalize this approach, so that e.g. layouts are emitted only once, and then referred to afterwards - not just for primitive types, but also for everything else (struct, typedef, etc.). This would minimize the amount of layouts we store in the constant classes. Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/620 From mcimadamore at openjdk.java.net Mon Nov 29 16:13:14 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 29 Nov 2021 16:13:14 GMT Subject: [foreign-jextract] Integrated: 8277830: jextract generated code should not depend on Java layouts In-Reply-To: References: Message-ID: <9UPXDmxSot8wQ9g3cc8uFwX3zS6fdaor9rKmCZ7Xxkw=.6e9fbd3a-20d7-482b-97b4-0eb7d53cb217@github.com> On Mon, 29 Nov 2021 14:09:29 GMT, Maurizio Cimadamore wrote: > This patch tweaks jextract generation, so that a new constant class is emitted, namely `Constant$root`, which contains the definition of all basic C primitive types. These are declared with the correct alignment constraints, depending on platforms. > > Every other layout created by jextract will depend on these shared layouts constants, so that jextract code doesn't depend on alignment choices in `ValueLayout` constants. > > In the future, we should probably generalize this approach, so that e.g. layouts are emitted only once, and then referred to afterwards - not just for primitive types, but also for everything else (struct, typedef, etc.). This would minimize the amount of layouts we store in the constant classes. This pull request has now been integrated. Changeset: 95d344ce Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/95d344ceb9bcb20ce8b4d7ed6d957b6eb01d3ffc Stats: 148 lines in 8 files changed: 90 ins; 37 del; 21 mod 8277830: jextract generated code should not depend on Java layouts Reviewed-by: sundar, jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/620 From jboes at openjdk.java.net Mon Nov 29 16:55:32 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 29 Nov 2021 16:55:32 GMT Subject: [foreign-memaccess+abi] RFR: 8277945: Use snippets in jdk.incubator.foreign API documentation Message-ID: This change replaces `
{@code ...}
` blocks with the new `@snippet` tag. ------------- Commit messages: - initial commit Changes: https://git.openjdk.java.net/panama-foreign/pull/621/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=621&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277945 Stats: 301 lines in 10 files changed: 0 ins; 0 del; 301 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/621.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/621/head:pull/621 PR: https://git.openjdk.java.net/panama-foreign/pull/621 From psandoz at openjdk.java.net Mon Nov 29 23:12:19 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 29 Nov 2021 23:12:19 GMT Subject: [foreign-memaccess+abi] RFR: 8277945: Use snippets in jdk.incubator.foreign API documentation In-Reply-To: References: Message-ID: On Mon, 29 Nov 2021 16:51:06 GMT, Julia Boes wrote: > This change replaces `
{@code ...}
` blocks with the new `@snippet` tag. Looks good. It seems harder to validate the snippets right now, perhaps later when there is jtreg support. ------------- Marked as reviewed by psandoz (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/621 From sundar at openjdk.java.net Tue Nov 30 03:57:19 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 30 Nov 2021 03:57:19 GMT Subject: [foreign-memaccess+abi] RFR: 8277945: Use snippets in jdk.incubator.foreign API documentation In-Reply-To: References: Message-ID: <-Bwc8Gw5yX2p11tqGVtGt6SKBHcEsQgp1pA4vvPW6cU=.1029238e-5ee8-436d-99c4-218c279f746d@github.com> On Mon, 29 Nov 2021 16:51:06 GMT, Julia Boes wrote: > This change replaces `
{@code ...}
` blocks with the new `@snippet` tag. Should we add lang=java to snippets? That'll help in syntax colouring using third-party js+css. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/621 From jboes at openjdk.java.net Tue Nov 30 10:27:33 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 30 Nov 2021 10:27:33 GMT Subject: [foreign-memaccess+abi] RFR: 8277945: Use snippets in jdk.incubator.foreign API documentation In-Reply-To: <-Bwc8Gw5yX2p11tqGVtGt6SKBHcEsQgp1pA4vvPW6cU=.1029238e-5ee8-436d-99c4-218c279f746d@github.com> References: <-Bwc8Gw5yX2p11tqGVtGt6SKBHcEsQgp1pA4vvPW6cU=.1029238e-5ee8-436d-99c4-218c279f746d@github.com> Message-ID: On Tue, 30 Nov 2021 03:53:45 GMT, Athijegannathan Sundararajan wrote: > Should we add lang=java to snippets? That'll help in syntax colouring using third-party js+css. For inline snippets, the default value for lang is java, so we can omit it. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/621 From maurizio.cimadamore at oracle.com Tue Nov 30 13:05:36 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 30 Nov 2021 13:05:36 +0000 Subject: Java value layout constants In-Reply-To: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> References: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> Message-ID: <922d1df8-24e6-896f-1c7c-f9ebfff4d104@oracle.com> Hi all, there has been a twist in this story. When looking at the PR [1], Paul and I were reminded of a failure mode which occurred last year [2], where accessing double elements copied into a segment backed by a byte[] could sometimes fail (e.g. on x86 platform) because of misaligned access. The moral of the story (more details below) is that enforcing alignment on heap segments is hit-and-miss in the current implementation, and can reveal sharp edges (e.g. some operation might reveal alignment decisions which might be JVM implementation dependent). Because of this, I'd like to revise our plan, and leave Java layout constants as they are now (e.g. unaligned) in Java 18, while we fix handling of alignment and heap segments under the hood. Given the timeframe, this seems the most sensible choice. If you are interested in more details, please continue reading below. The issue in [2] revealed that, while on x64 platform we can rely on the first element of an array T[], for any T to be 64-bit aligned, that is not the case in x86. The issue has to do with how array object headers are laid out. The layout of a Java array is typically defined as follows (see [3]) 1. 4-byte mark 2. 4/8-byte class pointer 3. 4-byte length 4. optional padding 5. elements Now, in x64 platforms, the class pointer in (2) is typically 64-bits. This means that the header part of an array is 16 bytes in total, which in turn means that the first element of the array is always 8-byte aligned (because all heap objects are at least 8-byte aligned, regardless of platform, see [4]). What about x86? Well, in x86 the class pointer is only 4 bytes, which means the header is 12 bytes. This gives a 32-bit VM more options: if the array is a int[], a VM might just store that element at offset 12, as that offset is 4-byte aligned. But if the array is a long[], the VM needs to insert some padding, so that the first element of the array will be at least 8-byte aligned (otherwise atomic operation will fail). This logic is reflected in [5], where the VM makes sure that for long[] and double[], elements are always (regardless of 32 vs. 64 bits) stored at offsets that are 64-bit aligned. This obviously creates an asymmetry: we could create a memory segment backed by a double[], copy its elements into a segment backed by a byte[], and then try to retrieve 64-bit aligned double values from the second memory segment. This operation will succeed on 64-bit platforms (as byte[] and double[] have same alignment constraints there), but will fail spuriously on x86 platforms. But this is not just about 32bit vs 64bit - other VM implementations might have different opinion on what alignment of array elements should be, and enhancements such as those proposed by Project Lilliput [6] can have profound implications in this area. Where does this leave us? Checking for alignment is definitively useful to prevent bugs - but the simple check carried out by the memory segment API ends up *leaking* implementation decisions as to how array elements are laid out. Ideally we'd like to have an API whose failures are predictable, so the status quo isn't great. Note that the real issue here is not whether layout constants should be aligned or not - or what their alignment (if any) should be. The real issue is that the memory segment API does not enforce alignment in all situations, especially around memory copy. It is in fact possible to copy elements from a segment backed from an array that has _more_ alignment constraints into a segment backed by an array that has _less_ alignment constraints, w/o errors, which is a potential source of (alignment) bugs. We believe (thanks John!) we have a story to generalize the alignment checks to heap segments, in a way that no implementation-dependent information is leaked - the basic idea is to observe that native segments and heap segments are different beasts: when working with a native segment we can always know the alignment properties of any address inside that segment (the alignment is a property of the bit pattern of that address - e.g. how many zeros appear at the end of the address). But heap segments addresses are *virtualized* - so there is nothing for the API to check (e.g. heap segments do not have a base address, so to speak). In order to have reliable alignment checks which work on both native and heap segments, our API should assume that memory addresses produced by an heap segments can never be more aligned than the element size of the Java array backing that heap segment. This means that if we have a segment backed by a short[], the *maximum alignment* constraint supported by this segment is, for instance, 2. If we try to store an aligned int inside this segment, an error should occur (whether the store occur as a result of dereference, or bulk-copy), as there is no guarantee that this operation is well-defined across all platforms. Conversely, a native segment has _no_ maximum alignment. This strategy allows the API to implement alignment checks on heap segments in a predictable fashion, so that the outcome of an alignment check does not depend on the assumptions of a particular architecture, or on the set of enabled VM features. When this underlying issue is fixed, we can then have a discussion as to whether layout constants in ValueLayout should be aligned-by-default or not. Having aligned layout constants might be useful to prevent bugs, but will limit the flexibility of the API. But that's a decision for another day. [1] - https://git.openjdk.java.net/jdk/pull/6589 [2] - https://bugs.openjdk.java.net/browse/JDK-8255343 [3] - https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/arrayOop.hpp#L35 [4] - https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals.hpp#L132 [5] - https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/arrayOop.hpp#L70 [6] - https://openjdk.java.net/projects/lilliput/ Maurizio On 25/11/2021 15:52, Maurizio Cimadamore wrote: > Hi, > This is a followup of the disccussion that started in [1]. In the new > changes slated for Java 18, the set of Java value layout constants are > all byte-aligned (e.g. alignment constraints are not set). The > motivation for this is mostly historical (but there's also a > performance twist, see below): the dereference primitives in > MemoryAccess used to setup var handles based on non-aligned layouts. > So, to preserve compatibility with what we had before, we opted to > "relax" alignment constraints on the JAVA_XYZ layout constants in > ValueLayout. During the development of the new dereference API, some > issues arised around alignment checks and memory copy [2]; which also > contributed to consolidate the feeling that Java layout constants > should be unaligned. > > Now, while it's always possible, for clients, to go back to the > desired alignment constraints (e.g. by defining custom layout > constants), from the discussion it emerged that it can be somewhat > confusing/surprising having a layout constant called JAVA_INT, whose > alignment is not the VM alignment for a Java int value. > > For this reason, I'd like to propose a small tweak, which would > essentially revert alignment constraints for Java layout constants to > what they were in 17. In other words, let's keep the "good" JAVA_XYZ > names for the _true_ Java layouts (including alignment as seen by VM). > If clients want to create unaligned constants they can do so, as they > can also create big-endian constants where needed. In the majority of > cases, since access will be aligned (for performance reasons), this > will not really change much for clients. But some of those clients > that need to pack data structures more (Lucene?) will need to define > their own packed/unaligned layout constants. > > Does that seem like an acceptable compromise? > > A patch for these changes is available here: > > https://github.com/mcimadamore/jdk/tree/value_layout_align > > While testing it, I was reminded (once more) that access with > alignment constraints is currently slower than access w/o alignment > constraints - which has to do with C2 not hoisting alignment checks in > cases like this: > > ((segmentBaseAddress + accessedOffset) & alignmentMask) == 0 > > Here, segmentBaseAddress is a loop invariant, and the accessedOffset > depends on the loop variable. So, it is in principle possible for the > VM to hoist the check for baseAddress and to eliminate the alignment > check for the offset (which would come from BCE analysis). But this is > not how things work today. The patch works around this, by using > different var handles for when the accessed offset is provably aligned > (e.g. when using the getAtIndex/setAtIndex APIs). Even with those > workarounds, calling getAtIndex/setAtIndex on a MemoryAddress is still > slower than on a MemorySegment, because of the way in which we try to > workaround the long loop optimization problem. Luckily a fix for that > problem [3] has been integrated in JDK 18, which means we will remove > these implementation workaround, which will help making performance > more stable across the board. > > If the changes in this patch seem good, I'm happy to try and integrate > this into 18. > > Cheers > Maurizio > > [1] - > https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015805.html > [2] - > https://github.com/openjdk/panama-foreign/pull/555#issuecomment-865115787 > [3] - https://github.com/openjdk/jdk/pull/2045 > > > From john.r.rose at oracle.com Tue Nov 30 19:22:10 2021 From: john.r.rose at oracle.com (John Rose) Date: Tue, 30 Nov 2021 19:22:10 +0000 Subject: Java value layout constants In-Reply-To: <922d1df8-24e6-896f-1c7c-f9ebfff4d104@oracle.com> References: <9c549ecd-d809-a77b-134b-275515cc579f@oracle.com> <922d1df8-24e6-896f-1c7c-f9ebfff4d104@oracle.com> Message-ID: <4516295A-A790-43C3-8872-5EFB3C949C0E@oracle.com> On Nov 30, 2021, at 5:05 AM, Maurizio Cimadamore > wrote: In order to have reliable alignment checks which work on both native and heap segments, our API should assume that memory addresses produced by an heap segments can never be more aligned than the element size of the Java array backing that heap segment. This means that if we have a segment backed by a short[], the *maximum alignment* constraint supported by this segment is, for instance, 2. If we try to store an aligned int inside this segment, an error should occur (whether the store occur as a result of dereference, or bulk-copy), as there is no guarantee that this operation is well-defined across all platforms. Conversely, a native segment has _no_ maximum alignment. Yes, this is the key new move. It hides (?abstracts away?) any alignment that any particular position in a byte array might have, relative to a storage unit larger than a byte. It hides any alignment stronger than 16-bit alignment at every position in a char array, even if (physically speaking) some positions in a char array *are* in fact more aligned than others. I think one net effect of this is to push users away from byte arrays and towards long arrays, if they choose to use aligned layouts with mixed types. You can push and pull aligned bytes (and ints and shorts) into a long array, but you can?t push and pull aligned longs into a byte array, under these new rules, no matter how clever you are about picking the offset into the byte array. Of course, you can *always* push and pull *unaligned* values of any layout into any primitive array. There?s always a (native order) byte-wise view of any such array. If you want a mix of aligned and unaligned accesses, then use a long array for backing store. This scales up to post-64-bit types such as aligned vectors. You need a backing store with hyper-alignment, and the segment holding such a hyper-aligned array (of some invisible type like uint128_t) would allow aligned accesses up to 128 bits but no further, even if the user were ?lucky? in picking an offset that was more physically aligned. (We could consider abstracting away from native order, pretending that the JVM makes a hidden private decision about byte order for each array. In that case both alignment and size would have to match exactly for such an array. That seems to be too much abstraction.)