From serb at openjdk.java.net Sat May 1 01:44:54 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 1 May 2021 01:44:54 GMT Subject: RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0 In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 20:07:53 GMT, Phil Race wrote: > Upgrade to harfbuzz 2.8 I assume the build using bundled lib is fine on all our platforms. ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3826 From vromero at openjdk.java.net Sun May 2 02:10:26 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 2 May 2021 02:10:26 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v6] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/2744f615..304fd76a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=04-05 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From jlahoda at openjdk.java.net Mon May 3 16:41:54 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 3 May 2021 16:41:54 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v6] In-Reply-To: References: Message-ID: On Sun, 2 May 2021 02:10:26 GMT, Vicente Romero wrote: >> Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) >> >> Thanks >> >> note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build javac changes look good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3526 From psandoz at openjdk.java.net Mon May 3 21:43:54 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 3 May 2021 21:43:54 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 21:11:26 GMT, Sandhya Viswanathan wrote: >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> This work is part of second round of incubation of the Vector API. >> JEP: https://bugs.openjdk.java.net/browse/JDK-8261663 >> >> Please review. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge master > - remove whitespace > - Merge master > - Small fix > - cleanup > - x86 short vector math optimization for Vector API Tier 1 to 3 tests pass for the default set of build profiles. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Mon May 3 22:11:59 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Mon, 3 May 2021 22:11:59 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge master >> - remove whitespace >> - Merge master >> - Small fix >> - cleanup >> - x86 short vector math optimization for Vector API > > Tier 1 to 3 tests pass for the default set of build profiles. @PaulSandoz Thanks a lot for running through the tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From prr at openjdk.java.net Mon May 3 23:04:52 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 3 May 2021 23:04:52 GMT Subject: RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0 In-Reply-To: References: Message-ID: On Sat, 1 May 2021 01:42:04 GMT, Sergey Bylokhov wrote: > I assume the build using bundled lib is fine on all our platforms. Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3826 From dholmes at openjdk.java.net Mon May 3 23:47:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 3 May 2021 23:47:06 GMT Subject: RFR: 8266465: Add wildcard to JTwork/JTreport exclude in jib-profiles.js Message-ID: <3ZYHSznZtBvYFj9zhlQn-F_z-4Y4nrvPZ83AMuqfdPc=.47cb28ae-c12e-42d4-a1ca-7c3cf0d9f39d@github.com> If you stash away jtreg test results in a specific JTwork directory this can causes problem creating a jib source bundle. Simple fix is to add a wildcard to the JTwork and JTreport exclude entries. Thanks, David ------------- Commit messages: - 8266465: Add wildcard to JTwork/JTreport exclude in jib-profiles.js Changes: https://git.openjdk.java.net/jdk/pull/3847/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3847&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266465 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3847.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3847/head:pull/3847 PR: https://git.openjdk.java.net/jdk/pull/3847 From erikj at openjdk.java.net Tue May 4 12:43:46 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 4 May 2021 12:43:46 GMT Subject: RFR: 8266465: Add wildcard to JTwork/JTreport exclude in jib-profiles.js In-Reply-To: <3ZYHSznZtBvYFj9zhlQn-F_z-4Y4nrvPZ83AMuqfdPc=.47cb28ae-c12e-42d4-a1ca-7c3cf0d9f39d@github.com> References: <3ZYHSznZtBvYFj9zhlQn-F_z-4Y4nrvPZ83AMuqfdPc=.47cb28ae-c12e-42d4-a1ca-7c3cf0d9f39d@github.com> Message-ID: On Mon, 3 May 2021 23:40:24 GMT, David Holmes wrote: > If you stash away jtreg test results in a specific JTwork directory this can causes problem creating a jib source bundle. Simple fix is to add a wildcard to the JTwork and JTreport exclude entries. > > Thanks, > David Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3847 From prr at openjdk.java.net Tue May 4 18:25:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 4 May 2021 18:25:57 GMT Subject: Integrated: 8261169: Upgrade HarfBuzz to the latest 2.8.0 In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 20:07:53 GMT, Phil Race wrote: > Upgrade to harfbuzz 2.8 This pull request has now been integrated. Changeset: 80323b7f Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/80323b7f66541e24177d02cc668a2eb9267962b9 Stats: 13120 lines in 123 files changed: 7021 ins; 2757 del; 3342 mod 8261169: Upgrade HarfBuzz to the latest 2.8.0 Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/3826 From fw at deneb.enyo.de Tue May 4 19:31:03 2021 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 04 May 2021 21:31:03 +0200 Subject: [OpenJDK 2D-Dev] RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0 In-Reply-To: (Phil Race's message of "Fri, 30 Apr 2021 20:14:22 GMT") References: Message-ID: <87bl9ql2iw.fsf@mid.deneb.enyo.de> * Phil Race: > Upgrade to harfbuzz 2.8 I believe this causes a build failure with GCC 8.3 (from Debian buster): * For target support_native_java.desktop_libfontmanager_hb-ot-shape-complex-use.o: In file included from ?/jdk/src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use.cc:33: hb-ot-shape-complex-use-machine.rl: In instantiation of 'machine_index_t::machine_index_t(const machine_index_t&) [with Iter = hb_zip_iter_t, hb_filter_iter_t, hb_array_t >, find_syllables_use(hb_buffer_t*)::, const&, 0>, find_syllables_use(hb_buffer_t*)::)>, const&, 0> >]': hb-ot-shape-complex-use-machine.rl:249:11: required from here hb-ot-shape-complex-use-machine.rl:194:9: error: base class 'struct hb_iter_with_fallback_t, hb_filter_iter_t, hb_array_t >, find_syllables_use(hb_buffer_t*)::, const&, 0>, find_syllables_use(hb_buffer_t*)::)>, const&, 0> > >, hb_pair_t > >' should be explicitly initialized in the copy constructor [-Werror=extra] cc1plus: all warnings being treated as errors From philip.race at oracle.com Tue May 4 20:24:40 2021 From: philip.race at oracle.com (Philip Race) Date: Tue, 4 May 2021 13:24:40 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0 In-Reply-To: <87bl9ql2iw.fsf@mid.deneb.enyo.de> References: <87bl9ql2iw.fsf@mid.deneb.enyo.de> Message-ID: <2bb9ee26-f803-5035-f6ee-865de7c52634@oracle.com> I built with gcc 10.3 https://bugs.openjdk.java.net/browse/JDK-8265373 I expect we can accommodate disabling one more warning to support more compilers. -phil. On 5/4/21 12:31 PM, Florian Weimer wrote: > * Phil Race: > >> Upgrade to harfbuzz 2.8 > I believe this causes a build failure with GCC 8.3 (from Debian > buster): > > * For target support_native_java.desktop_libfontmanager_hb-ot-shape-complex-use.o: > In file included from ?/jdk/src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use.cc:33: > hb-ot-shape-complex-use-machine.rl: In instantiation of 'machine_index_t::machine_index_t(const machine_index_t&) [with Iter = hb_zip_iter_t, hb_filter_iter_t, hb_array_t >, find_syllables_use(hb_buffer_t*)::, const&, 0>, find_syllables_use(hb_buffer_t*)::)>, const&, 0> >]': > hb-ot-shape-complex-use-machine.rl:249:11: required from here > hb-ot-shape-complex-use-machine.rl:194:9: error: base class 'struct hb_iter_with_fallback_t, hb_filter_iter_t, hb_array_t >, find_syllables_use(hb_buffer_t*)::, const&, 0>, find_syllables_use(hb_buffer_t*)::)>, const&, 0> > >, hb_pair_t > >' should be explicitly initialized in the copy constructor [-Werror=extra] > cc1plus: all warnings being treated as errors From dholmes at openjdk.java.net Tue May 4 22:10:51 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 4 May 2021 22:10:51 GMT Subject: Integrated: 8266465: Add wildcard to JTwork/JTreport exclude in jib-profiles.js In-Reply-To: <3ZYHSznZtBvYFj9zhlQn-F_z-4Y4nrvPZ83AMuqfdPc=.47cb28ae-c12e-42d4-a1ca-7c3cf0d9f39d@github.com> References: <3ZYHSznZtBvYFj9zhlQn-F_z-4Y4nrvPZ83AMuqfdPc=.47cb28ae-c12e-42d4-a1ca-7c3cf0d9f39d@github.com> Message-ID: On Mon, 3 May 2021 23:40:24 GMT, David Holmes wrote: > If you stash away jtreg test results in a specific JTwork directory this can causes problem creating a jib source bundle. Simple fix is to add a wildcard to the JTwork and JTreport exclude entries. > > Thanks, > David This pull request has now been integrated. Changeset: 61365d5f Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/61365d5f58dae2dbc2aac20e62c656f931e63b66 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8266465: Add wildcard to JTwork/JTreport exclude in jib-profiles.js Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3847 From sviswanathan at openjdk.java.net Tue May 4 22:15:59 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 4 May 2021 22:15:59 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 21:11:26 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge master > - remove whitespace > - Merge master > - Small fix > - cleanup > - x86 short vector math optimization for Vector API @vnkozlov @AlanBateman @rose00 Looking forward to your review and feedback. This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator](https://openjdk.java.net/jeps/414), in preparation for when targeted. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From jiefu at openjdk.java.net Tue May 4 23:32:53 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 4 May 2021 23:32:53 GMT Subject: RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0 In-Reply-To: References: Message-ID: On Mon, 3 May 2021 23:02:01 GMT, Phil Race wrote: >> I assume the build using bundled lib is fine on all our platforms. > >> I assume the build using bundled lib is fine on all our platforms. > > Yes. Hi @prrace , Our CI/CD got the following build errors on x86_64 with gcc 8.3.1: Building target 'images' in configuration 'linux-x86_64-server-fastdebug' Updating support/modules_libs/java.base/server/libjvm.so due to 1 file(s) In file included from /home/jvm/jdk/src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use.cc:33: hb-ot-shape-complex-use-machine.rl: In instantiation of 'machine_index_t::machine_index_t(const machine_index_t&) [with Iter = hb_zip_iter_t, hb_filter_iter_t, hb_array_t >, find_syllables_use(hb_buffer_t*)::, const&, 0>, find_syllables_use(hb_buffer_t*)::)>, const&, 0> >]': hb-ot-shape-complex-use-machine.rl:249:11: required from here hb-ot-shape-complex-use-machine.rl:194:9: error: base class 'struct hb_iter_with_fallback_t, hb_filter_iter_t, hb_array_t >, find_syllables_use(hb_buffer_t*)::, const&, 0>, find_syllables_use(hb_buffer_t*)::)>, const&, 0> > >, hb_pair_t > >' should be explicitly initialized in the copy constructor [-Werror=extra] cc1plus: all warnings being treated as errors gmake[3]: *** [/home/jvm/jdk/build/linux-x86_64-server-fastdebug/support/native/java.desktop/libfontmanager/hb-ot-shape-complex-use.o] Error 1 gmake[2]: *** [java.desktop-libs] Error 1 ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-fastdebug' (exit code 2) === Output from failing command(s) repeated here === * For target support_native_java.desktop_libfontmanager_hb-ot-shape-complex-use.o: In file included from /home/jvm/jdk/src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use.cc:33: hb-ot-shape-complex-use-machine.rl: In instantiation of 'machine_index_t::machine_index_t(const machine_index_t&) [with Iter = hb_zip_iter_t, hb_filter_iter_t, hb_array_t >, find_syllables_use(hb_buffer_t*)::, const&, 0>, find_syllables_use(hb_buffer_t*)::)>, const&, 0> >]': hb-ot-shape-complex-use-machine.rl:249:11: required from here hb-ot-shape-complex-use-machine.rl:194:9: error: base class 'struct hb_iter_with_fallback_t, hb_filter_iter_t, hb_array_t >, find_syllables_use(hb_buffer_t*)::, const&, 0>, find_syllables_use(hb_buffer_t*)::)>, const&, 0> > >, hb_pair_t > >' should be explicitly initialized in the copy constructor [-Werror=extra] cc1plus: all warnings being treated as errors * All command lines available in /home/jvm/jdk/build/linux-x86_64-server-fastdebug/make-support/failure-logs. Could you please have a look? I'm on a vacation this week. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3826 From stuefe at openjdk.java.net Wed May 5 07:41:51 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 07:41:51 GMT Subject: RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0 In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 20:07:53 GMT, Phil Race wrote: > Upgrade to harfbuzz 2.8 Same here. In my case it breaks with gcc 7.5.0, which I believe is still supported. I opened https://bugs.openjdk.java.net/browse/JDK-8266545. ------------- PR: https://git.openjdk.java.net/jdk/pull/3826 From stuefe at openjdk.java.net Wed May 5 07:57:49 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 5 May 2021 07:57:49 GMT Subject: RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0 In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 20:07:53 GMT, Phil Race wrote: > Upgrade to harfbuzz 2.8 https://github.com/openjdk/jdk/pull/3873 ------------- PR: https://git.openjdk.java.net/jdk/pull/3826 From mbaesken at openjdk.java.net Wed May 5 12:41:57 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 5 May 2021 12:41:57 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 In-Reply-To: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> Message-ID: On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote: > Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS issue. > > I fixed the issue in the harfbuzz sources, but I am not sure of the policy here. Do we modify the harfbuzz sources or leave them untouched? Advice is welcome. > > The patch fixes linux x64 fastdebug and opt build for me. Looks good to me, thanks Thomas ! ------------- Marked as reviewed by mbaesken (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3873 From github.com+19194678+scientificware at openjdk.java.net Wed May 5 16:43:08 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Wed, 5 May 2021 16:43:08 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home Message-ID: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> This concern [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. The expect value is `"Must set property 'dtd_home'"` And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? ------------- Commit messages: - Change test none dtd_home property is set. Changes: https://git.openjdk.java.net/jdk/pull/3626/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3626&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265909 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3626.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3626/head:pull/3626 PR: https://git.openjdk.java.net/jdk/pull/3626 From github.com+19194678+scientificware at openjdk.java.net Wed May 5 16:43:08 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Wed, 5 May 2021 16:43:08 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home In-Reply-To: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> Message-ID: On Thu, 22 Apr 2021 13:47:03 GMT, ScientificWare wrote: > This concern [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). > > In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. > > So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. > > The expect value is `"Must set property 'dtd_home'"` > > And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? Simple reproducer : In raw mode, save the 4 java files from [https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilde](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder) in the folder `/test_dtdbuilder` for example. In this folder type following commands : `javac -d . *.java` `java build.tools.dtdbuilder.DTDBuilder html32` ------------- PR: https://git.openjdk.java.net/jdk/pull/3626 From stuefe at openjdk.java.net Thu May 6 03:51:49 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 03:51:49 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 In-Reply-To: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> Message-ID: On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote: > Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS issue. > > I fixed the issue in the harfbuzz sources, but I am not sure of the policy here. Do we modify the harfbuzz sources or leave them untouched? Advice is welcome. > > The patch fixes linux x64 fastdebug and opt build for me. Ping. Anyone? ------------- PR: https://git.openjdk.java.net/jdk/pull/3873 From stuefe at openjdk.java.net Thu May 6 04:32:51 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 04:32:51 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 In-Reply-To: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> Message-ID: On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote: > Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS issue. > > I fixed the issue in the harfbuzz sources, but I am not sure of the policy here. Do we modify the harfbuzz sources or leave them untouched? Advice is welcome. > > The patch fixes linux x64 fastdebug and opt build for me. I issued an upstream PR: https://github.com/harfbuzz/harfbuzz/pull/2973 ------------- PR: https://git.openjdk.java.net/jdk/pull/3873 From shade at openjdk.java.net Thu May 6 06:19:49 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 6 May 2021 06:19:49 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 In-Reply-To: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> Message-ID: <2XipTG2NRASjQkhNmtCnZqN0VcS4TuKLRlPMaq-61Ow=.8f55ac70-ff9c-45d5-a675-909fde856cbe@github.com> On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote: > Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS issue. > > I fixed the issue in the harfbuzz sources, but I am not sure of the policy here. Do we modify the harfbuzz sources or leave them untouched? Advice is welcome. > > The patch fixes linux x64 fastdebug and opt build for me. FWIW, current jdk master builds fine with gcc 9.3.0. It fails with gcc 6.3.0 to me. I am unaware of the policy of changing the Harfbuzz sources too. If we are changing the Harfbuzz sources, I prefer the multi-line form you did in Harfbuzz PR, though: https://github.com/harfbuzz/harfbuzz/pull/2973 -- it would also simplify the merge. But there is an alternative, disable the warning and then wait for Harfbuzz fix to drop: diff --git a/make/modules/java.desktop/lib/Awt2dLibraries.gmk b/make/modules/java.desktop/lib/Awt2dLibraries.gmk index ff5fa00c720..627aa51ebdf 100644 --- a/make/modules/java.desktop/lib/Awt2dLibraries.gmk +++ b/make/modules/java.desktop/lib/Awt2dLibraries.gmk @@ -465,7 +465,7 @@ else HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ - maybe-uninitialized class-memaccess unused-result + maybe-uninitialized class-memaccess unused-result extra HARFBUZZ_DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \ tautological-constant-out-of-range-compare int-to-pointer-cast \ undef missing-field-initializers range-loop-analysis \ ------------- PR: https://git.openjdk.java.net/jdk/pull/3873 From stuefe at openjdk.java.net Thu May 6 06:58:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 06:58:16 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 [v2] In-Reply-To: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> Message-ID: > Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS issue. > > I fixed the issue in the harfbuzz sources, but I am not sure of the policy here. Do we modify the harfbuzz sources or leave them untouched? Advice is welcome. > > The patch fixes linux x64 fastdebug and opt build for me. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: switch off warning in build instead of fixing it ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3873/files - new: https://git.openjdk.java.net/jdk/pull/3873/files/dd0f4d29..bcdc7a54 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3873&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3873&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3873/head:pull/3873 PR: https://git.openjdk.java.net/jdk/pull/3873 From stuefe at openjdk.java.net Thu May 6 06:58:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 06:58:16 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 In-Reply-To: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> Message-ID: On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote: > Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS issue. > > I fixed the issue in the harfbuzz sources, but I am not sure of the policy here. Do we modify the harfbuzz sources or leave them untouched? Advice is welcome. > > The patch fixes linux x64 fastdebug and opt build for me. > FWIW, current jdk master builds fine with gcc 9.3.0. It fails with gcc 6.3.0 to me. > > I am unaware of the policy of changing the Harfbuzz sources too. If we are changing the Harfbuzz sources, I prefer the multi-line form you did in Harfbuzz PR, though: [harfbuzz/harfbuzz#2973](https://github.com/harfbuzz/harfbuzz/pull/2973) -- it would also simplify the merge. > > But there is an alternative, disable the warning and then wait for Harfbuzz fix to drop: > > ``` > diff --git a/make/modules/java.desktop/lib/Awt2dLibraries.gmk b/make/modules/java.desktop/lib/Awt2dLibraries.gmk > index ff5fa00c720..627aa51ebdf 100644 > --- a/make/modules/java.desktop/lib/Awt2dLibraries.gmk > +++ b/make/modules/java.desktop/lib/Awt2dLibraries.gmk > @@ -465,7 +465,7 @@ else > > HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing > HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ > - maybe-uninitialized class-memaccess unused-result > + maybe-uninitialized class-memaccess unused-result extra > HARFBUZZ_DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \ > tautological-constant-out-of-range-compare int-to-pointer-cast \ > undef missing-field-initializers range-loop-analysis \ > ``` You are right, that is much better. Why did this not occur to me. I will do this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3873 From stuefe at openjdk.java.net Thu May 6 06:58:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 06:58:16 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 [v2] In-Reply-To: <2XipTG2NRASjQkhNmtCnZqN0VcS4TuKLRlPMaq-61Ow=.8f55ac70-ff9c-45d5-a675-909fde856cbe@github.com> References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> <2XipTG2NRASjQkhNmtCnZqN0VcS4TuKLRlPMaq-61Ow=.8f55ac70-ff9c-45d5-a675-909fde856cbe@github.com> Message-ID: On Thu, 6 May 2021 06:16:36 GMT, Aleksey Shipilev wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> switch off warning in build instead of fixing it > > FWIW, current jdk master builds fine with gcc 9.3.0. It fails with gcc 6.3.0 to me. > > I am unaware of the policy of changing the Harfbuzz sources too. If we are changing the Harfbuzz sources, I prefer the multi-line form you did in Harfbuzz PR, though: https://github.com/harfbuzz/harfbuzz/pull/2973 -- it would also simplify the merge. > > But there is an alternative, disable the warning and then wait for Harfbuzz fix to drop: > > > diff --git a/make/modules/java.desktop/lib/Awt2dLibraries.gmk b/make/modules/java.desktop/lib/Awt2dLibraries.gmk > index ff5fa00c720..627aa51ebdf 100644 > --- a/make/modules/java.desktop/lib/Awt2dLibraries.gmk > +++ b/make/modules/java.desktop/lib/Awt2dLibraries.gmk > @@ -465,7 +465,7 @@ else > > HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing > HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ > - maybe-uninitialized class-memaccess unused-result > + maybe-uninitialized class-memaccess unused-result extra > HARFBUZZ_DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \ > tautological-constant-out-of-range-compare int-to-pointer-cast \ > undef missing-field-initializers range-loop-analysis \ I changed the fix according to @shipilev suggestion. This avoids all the hassle of changing downstream HB sources. @shipilev can we consider this as trivial? ------------- PR: https://git.openjdk.java.net/jdk/pull/3873 From rrich at openjdk.java.net Thu May 6 07:56:53 2021 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 6 May 2021 07:56:53 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 [v2] In-Reply-To: References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> Message-ID: <2zaFEjtWDpfXVbkBnXjpLsQEGXM0-u9S0V5QlYPx6J4=.4bb3bcf6-da42-4c97-bc67-2ef45dd4b94b@github.com> On Thu, 6 May 2021 06:58:16 GMT, Thomas Stuefe wrote: >> Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS issue. >> >> I fixed the issue in the harfbuzz sources, but I am not sure of the policy here. Do we modify the harfbuzz sources or leave them untouched? Advice is welcome. >> >> The patch fixes linux x64 fastdebug and opt build for me. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > switch off warning in build instead of fixing it Looks good to me, thanks! Personally I'm building with gcc 9. I've test your fix successfully with gcc 7.5. Cheers, Richard. ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3873 From stuefe at openjdk.java.net Thu May 6 08:26:52 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 08:26:52 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 [v2] In-Reply-To: <2zaFEjtWDpfXVbkBnXjpLsQEGXM0-u9S0V5QlYPx6J4=.4bb3bcf6-da42-4c97-bc67-2ef45dd4b94b@github.com> References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> <2zaFEjtWDpfXVbkBnXjpLsQEGXM0-u9S0V5QlYPx6J4=.4bb3bcf6-da42-4c97-bc67-2ef45dd4b94b@github.com> Message-ID: On Thu, 6 May 2021 07:53:52 GMT, Richard Reingruber wrote: > Looks good to me, thanks! > Personally I'm building with gcc 9. I've test your fix successfully with gcc 7.5. > > Cheers, Richard. Thanks Richard! I tested the build on Debian with gcc 7 and gcc 9, it worked. Since I now have enough reviews, I'' push after the GHA are through ------------- PR: https://git.openjdk.java.net/jdk/pull/3873 From stuefe at openjdk.java.net Thu May 6 09:25:55 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 09:25:55 GMT Subject: Integrated: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 In-Reply-To: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> Message-ID: On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote: > Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS issue. > > I fixed the issue in the harfbuzz sources, but I am not sure of the policy here. Do we modify the harfbuzz sources or leave them untouched? Advice is welcome. > > The patch fixes linux x64 fastdebug and opt build for me. This pull request has now been integrated. Changeset: a86ee9b3 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/a86ee9b3f370b59caea2ae78169d13498560cd8e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 Reviewed-by: mbaesken, rrich ------------- PR: https://git.openjdk.java.net/jdk/pull/3873 From prr at openjdk.java.net Thu May 6 16:40:52 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 6 May 2021 16:40:52 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 [v2] In-Reply-To: References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> Message-ID: On Thu, 6 May 2021 06:58:16 GMT, Thomas Stuefe wrote: >> Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS issue. >> >> I fixed the issue in the harfbuzz sources, but I am not sure of the policy here. Do we modify the harfbuzz sources or leave them untouched? Advice is welcome. >> >> The patch fixes linux x64 fastdebug and opt build for me. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > switch off warning in build instead of fixing it The policy is to do what you ended up doing. We (almost) never modify 3rd party sources in such cases. About the only case is if a fix has already been pushed upstream then we might copy that fix. You did the right thing notifying upstream but still best to just disable this warning for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3873 From stuefe at openjdk.java.net Thu May 6 17:27:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 6 May 2021 17:27:53 GMT Subject: RFR: 8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 [v2] In-Reply-To: References: <_W_n22h_GKOHlSSK1jRwkYdJMJcJPaC8lGw5FiK_zU4=.6062b653-0552-49cf-adbe-69170469722c@github.com> Message-ID: <-Q3w9n9B19ZoydABTBeK0JukGVSX3hMUAD71_N1-sLU=.a960ae71-ee97-4e88-9ac5-bb5ddb9640c6@github.com> On Thu, 6 May 2021 16:38:52 GMT, Phil Race wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> switch off warning in build instead of fixing it > > The policy is to do what you ended up doing. We (almost) never modify 3rd party sources in such cases. > About the only case is if a fix has already been pushed upstream then we might copy that fix. > You did the right thing notifying upstream but still best to just disable this warning for now. Thanks @prrace. I agree this is the simplest way. Good that Aleksey had this idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/3873 From vromero at openjdk.java.net Thu May 6 19:06:41 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 6 May 2021 19:06:41 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v7] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero 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 11 additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - ... and 1 more: https://git.openjdk.java.net/jdk/compare/10336a26...0208dcf0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/304fd76a..0208dcf0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=05-06 Stats: 18908 lines in 391 files changed: 9887 ins; 4814 del; 4207 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From jiefu at tencent.com Mon May 10 06:24:06 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Mon, 10 May 2021 06:24:06 +0000 Subject: github PR fails to send RFR email Message-ID: <56D59455-8461-4823-B690-B5D92D868314@tencent.com> Hi all, I found my PR [1] fails to send RFR email. Is there anything wrong? Or am I missing something? Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/pull/3941 From lgxbslgx at gmail.com Mon May 10 07:03:57 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Mon, 10 May 2021 15:03:57 +0800 Subject: github PR fails to send RFR email In-Reply-To: <56D59455-8461-4823-B690-B5D92D868314@tencent.com> References: <56D59455-8461-4823-B690-B5D92D868314@tencent.com> Message-ID: Hi jie, The same problem occurred in my PR[1]. And this problem began yesterday and only affects newly issued PRs(about 5 PRs now). Similar problems have occurred in the past(also on *weekends*). The maintainers may fix it quickly during working time. CC'ing skara-dev at openjdk.java.net [1] https://github.com/openjdk/jdk/pull/3942 Best Regards, -- Guoxiong On Mon, May 10, 2021 at 2:24 PM jiefu(??) wrote: > Hi all, > > > > I found my PR [1] fails to send RFR email. > > > > Is there anything wrong? > > Or am I missing something? > > > > Thanks. > > Best regards, > > Jie > > > > [1] https://github.com/openjdk/jdk/pull/3941 > > From jiefu at tencent.com Mon May 10 07:06:43 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Mon, 10 May 2021 07:06:43 +0000 Subject: github PR fails to send RFR email(Internet mail) In-Reply-To: References: <56D59455-8461-4823-B690-B5D92D868314@tencent.com> Message-ID: Got it. Thanks for your kind reply. Best regards, Jie From: Guoxiong Li Date: Monday, May 10, 2021 at 3:04 PM To: "jiefu(??)" Cc: build-dev , "skara-dev at openjdk.java.net" Subject: Re: github PR fails to send RFR email(Internet mail) Hi jie, The same problem occurred in my PR[1]. And this problem began yesterday and only affects newly issued PRs(about 5 PRs now). Similar problems have occurred in the past(also on weekends). The maintainers may fix it quickly during working time. CC'ing skara-dev at openjdk.java.net [1] https://github.com/openjdk/jdk/pull/3942 Best Regards, -- Guoxiong On Mon, May 10, 2021 at 2:24 PM jiefu(??) > wrote: Hi all, I found my PR [1] fails to send RFR email. Is there anything wrong? Or am I missing something? Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/pull/3941 From jlahoda at openjdk.java.net Tue May 11 13:42:32 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 11 May 2021 13:42:32 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) Message-ID: This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): https://bugs.openjdk.java.net/browse/JDK-8213076 The current draft of the specification is here: http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html A summary of notable parts of the patch: -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. The specdiff for the change is here (to be updated): http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html ------------- Commit messages: - Trailing whitespaces. - Cleanup, reflecting review comments. - Merge branch 'master' into JDK-8262891 - JDK-8262891: Compiler implementation for Pattern Matching for switch Changes: https://git.openjdk.java.net/jdk/pull/3863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262891 Stats: 3927 lines in 70 files changed: 3636 ins; 97 del; 194 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From mcimadamore at openjdk.java.net Tue May 11 13:42:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 11 May 2021 13:42:50 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening. In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 100: > 98: * the {@code NameAndType} of the {@code InvokeDynamic} > 99: * structure and is stacked automatically by the VM. > 100: * @param labels non-null case labels - {@code String} and {@code Integer} constants Can these types be mixed? E.g. can I pass, as static args: `42`, `Runnable.class`, `"hello"` ? If not, should be document, and throw? src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 102: > 100: * @param labels non-null case labels - {@code String} and {@code Integer} constants > 101: * and {@code Class} instances > 102: * @return the index into {@code labels} of the target value, if the target Doesn't return an index. Returns a CallSite which, when invoked with an argument of type E (where E is the type of the target expression), returns the index into... src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java line 306: > 304: > 305: /** > 306: * Visits an GuardPatternTree node. Suggestion: * Visits a GuardPatternTree node. src/jdk.compiler/share/classes/com/sun/source/tree/TreeVisitor.java line 316: > 314: > 315: /** > 316: * Visits an AndPatternTree node. Is this comment correct? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1685: > 1683: log.error(DiagnosticFlag.SOURCE_LEVEL, selector.pos(), > 1684: Feature.PATTERN_SWITCH.error(this.sourceName)); > 1685: allowPatternSwitch = true; I assume this logic is to show only one error in case we're compiling multiple methods with pattern switches and preview features are not enabled? Is this consistent with what happens with other preview features though? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1725: > 1723: log.error(DiagnosticFlag.SOURCE_LEVEL, expr.pos(), > 1724: Feature.CASE_NULL.error(this.sourceName)); > 1725: allowCaseNull = true; Same here about error recovery and minimize messages - if this is what we'd like to do, perhaps centralizing the check in Preview would be better (so that e.g. we'd return that a given preview feature is not supported only once). src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1790: > 1788: if (isTotal) { > 1789: if (hasTotalPattern) { > 1790: log.error(pat.pos(), Errors.DuplicateTotalPattern); Hard to explain - but a lot of the code here feels more like it belongs to `Flow` than to `Attr`. E.g. these "duplicateXYZ" labels really want to say "unreachable code", I think. Is there a strong reason as to why all this code shouldn't (apart from code computing bindings) move to Flow? Seems that the logic is partially duplicated anyway... src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1861: > 1859: return null; > 1860: } > 1861: private Pair primaryType(JCPattern pat) { Maybe a record here would lead for better code (no boxing of Boolean, but, more importantly, better field names for fst/snd). More generally, now that we have records I think we should think twice before using Pairs :-) src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 757: > 755: } > 756: > 757: private TypeSymbol patternType(JCPattern p) { If we need to keep duplicated code, this could move to TreeInfo src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 757: > 755: } > 756: > 757: private TypeSymbol patternType(JCPattern p) { If we need to keep duplicated code, this could move to TreeInfo src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2917: > 2915: void reportEffectivelyFinalError(DiagnosticPosition pos, Symbol sym) { > 2916: String subKey = switch (currentTree.getTag()) { > 2917: case LAMBDA -> "lambda"; Can we make the switch return the fragment constant (e.g. Fragments.XYZ) rather than a String which is then re-wrapped? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3649: > 3647: if (!enumSwitch && !stringSwitch && !selector.type.isPrimitive() && > 3648: cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) { > 3649: //a switch over a boxed primitive, with a null case. Pick two constants that are Is this comment correct? If we're here, can't this be just any pattern switch? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3729: > 3727: if (cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) { > 3728: //for enum switches with case null, do: > 3729: //switch ($selector != null ? $mapVar[$selector.ordinal()] : -1) {...} Very clever trick to handle away null treatment with just an extra default label. I wonder if this logic isn't big enough to deserve its own `visitXYZSwitch` method, as we do for strings and enums in switch. It seems asymmetric that we do some bits of null handling here (in certain cases) but then enum switches will deal with null in a different way. We should probably test what kind of switch we're dealing with earlier, and then branch out to completely disjoint pieces of code, each with its own null handling src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MatchBindingsComputer.java line 124: > 122: // e.T = union(x.T, y.T) > 123: // e.F = intersection(x.F, y.F) (error recovery) > 124: List bindingsWhenTrue = Is this duplicate code for MatchBindingComputer::binary(AND) ? If so, should at least the impl delegate to that? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 193: > 191: : tree.expr.type; > 192: VarSymbol prevCurrentValue = currentValue; > 193: try { IIUC, the changes here are to handle recursion of pattern in the instanceof case - e.g. `x instanceof (Foo foo)`. If so, it would be nice to have that reflected in the comment above. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 305: > 303: selector = make.Ident(temp); > 304: } else { > 305: List staticArgTypes = List.of(syms.methodHandleLookupType, I guess strategy here is to convert the various labels into loadable constants and then pass them up to the bootstrap method which will give us back an int, which we'll use for a plain switch. If so, all this needs to be documented somehow. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 368: > 366: JCContinue continueSwitch = make.Continue(null); > 367: continueSwitch.target = tree; > 368: c.stats = c.stats.prepend(make.If(makeUnary(Tag.NOT, test).setType(syms.booleanType), I assume this is code which "resumes" to the following `case` if the pattern doesn't match. I guess in most cases the bootstrap method would do the check anyway - but I suppose that with guards, the bootstrap method, alone, cannot guarantee the match. Also, it seems like this requires backend support for `continue` in switch. Again, all this needs to be better documented, it's pretty hard to infer all this by looking at the code. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 776: > 774: } else { > 775: JCPattern pattern; > 776: JCExpression e = parsedType == null ? term(EXPR | TYPE | NOLAMBDA/* | NOINVOCATION*/) : parsedType; what's up with NO_INVOCATION? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3004: > 3002: JCCaseLabel label = parseCaseLabel(); > 3003: > 3004: //TODO: final What does this `todo` refers to? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3078: > 3076: } > 3077: Token twoBack; > 3078: boolean pattern = S.token(lookahead - 1).kind == IDENTIFIER && ((twoBack = S.token(lookahead - 2)).kind == IDENTIFIER || twoBack.kind == GT || twoBack.kind == GTGT || twoBack.kind == GTGTGT); tricky - but I think correct. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3085: > 3083: } > 3084: } > 3085: //XXX: modifiers! Another todo here src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 501: > 499: > 500: compiler.err.pattern.dominated=\ > 501: this pattern is dominated by a preceding pattern Not sure whether the concept of "dominance" is the one that will work best here. As I said elsewhere, this is, morally, unreachable code. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 520: > 518: > 519: compiler.err.multiple.patterns=\ > 520: multiple pattern declarations This text is very terse and doesn't really say what's wrong with the code. I think the point here is that we don't want code like this: case String s, Integer i: ... because this is morally: case String s: case Integer i: ... which is, again, fall-through to a pattern. Maybe, just reusing the same "fall-through" message would be ok here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Tue May 11 13:42:54 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 11 May 2021 13:42:54 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 20:48:34 GMT, Maurizio Cimadamore wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening. > > In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well. @mcimadamore, thanks a lot for the comments! I tried to reflect most of them in https://github.com/openjdk/jdk/pull/3863/commits/1a5a424139a52d0f93e16980c6b42cf29dd908ef - please let me know how that looks. Thanks! > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1790: > >> 1788: if (isTotal) { >> 1789: if (hasTotalPattern) { >> 1790: log.error(pat.pos(), Errors.DuplicateTotalPattern); > > Hard to explain - but a lot of the code here feels more like it belongs to `Flow` than to `Attr`. E.g. these "duplicateXYZ" labels really want to say "unreachable code", I think. Is there a strong reason as to why all this code shouldn't (apart from code computing bindings) move to Flow? Seems that the logic is partially duplicated anyway... `Attr` was always checking duplicated constants and duplicated default, so checking for pattern dominance (which could be seen as an extension to duplicate constant labels) and total patterns (which is an extension to duplicated default) here seemed reasonable. We also have a couple of other similar checks performed by `Attr`, like duplicated statement labels, or that exception types in multicatch are disjoint. These are checks that don't need DA/DU, while I think `Flow` does mostly checks that require DA/DU. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3649: > >> 3647: if (!enumSwitch && !stringSwitch && !selector.type.isPrimitive() && >> 3648: cases.stream().anyMatch(c -> TreeInfo.isNull(c.labels.head))) { >> 3649: //a switch over a boxed primitive, with a null case. Pick two constants that are > > Is this comment correct? If we're here, can't this be just any pattern switch? Patterns switches are resolved before Lower, so in Lower there should be no pattern switches. I'll add a comment in this sense at an appropriate place. > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 501: > >> 499: >> 500: compiler.err.pattern.dominated=\ >> 501: this pattern is dominated by a preceding pattern > > Not sure whether the concept of "dominance" is the one that will work best here. As I said elsewhere, this is, morally, unreachable code. The specification uses "dominance", so it seemed appropriate to use the same term that is used by the specification. We can say "unreachable code", of course, but it will not be consistent with what the specification says, and also with what we do for duplicate constant labels. Also considering code like: switch (o) { case A a -> {} case B b -> {} //error on this line } It may not be obvious why the code is "unreachable", while saying "dominated" might be more helpful/clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From mcimadamore at openjdk.java.net Tue May 11 13:42:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 11 May 2021 13:42:55 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 20:35:45 GMT, Maurizio Cimadamore wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 102: > >> 100: * @param labels non-null case labels - {@code String} and {@code Integer} constants >> 101: * and {@code Class} instances >> 102: * @return the index into {@code labels} of the target value, if the target > > Doesn't return an index. Returns a CallSite which, when invoked with an argument of type E (where E is the type of the target expression), returns the index into... It should also mention that the handle returned accepts a start index (which is used by the continue logic) ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From erikj at openjdk.java.net Tue May 11 13:56:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 11 May 2021 13:56:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: <5tkFlMzpxFP1UFGuwI7u0mpFCt_hExf6SLwQVCJnfJs=.8878adb9-f423-408a-9a62-41334467e49f@github.com> On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html make/CompileInterimLangtools.gmk line 52: > 50: > 51: $(eval $(call SetupCopyFiles, COPY_PREVIEW_FEATURES, \ > 52: FILES := $(TOPDIR)/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java $(TOPDIR)/src/java.base/share/classes/jdk/internal/javac/NoPreview.java, \ Please break this line (adding 4 additional space indent from the original line). Otherwise build changes ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From github.com+828220+forax at openjdk.java.net Tue May 11 14:24:54 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 11 May 2021 14:24:54 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 77: > 75: } > 76: > 77: private static MethodHandle typeInitHook(T receiver) { There is no point to have a type parameter here, private static MethodHandle typeInitHook(CallSite receiver) { will work the same src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 131: > 129: > 130: private static void verifyLabel(Object label) { > 131: if (Objects.isNull(label)) { `if (label == true) {` is more readable as said in the javadoc of `Objects.isNull` ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From naoto at openjdk.java.net Wed May 12 16:38:48 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 12 May 2021 16:38:48 GMT Subject: RFR: 8258795: Update IANA Language Subtag Registry to Version 2021-05-11 Message-ID: Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK. ------------- Commit messages: - Renaming the test case - LSR 2021-05-11 - LSR 2021-03-05 - LSR 2021-02-23 - LSR 2020-12-18 Changes: https://git.openjdk.java.net/jdk/pull/3998/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3998&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258795 Stats: 340 lines in 2 files changed: 327 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3998.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3998/head:pull/3998 PR: https://git.openjdk.java.net/jdk/pull/3998 From mcimadamore at openjdk.java.net Wed May 12 17:46:12 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 12 May 2021 17:46:12 GMT Subject: RFR: 8267043: IntelliJ project doesn't handle generated sources correctly Message-ID: Since generated sources are placed in the build folder, and since the build folder is indicated by the IntelliJ project settings as "project output", IntelliJ indexing blissfully ignores all the classes which are generated during the build. This simple patch fixes that, by simply pointing the project output to a non-existing folder inside the build path (called `idea`). ------------- Commit messages: - Redirect IntelliJ output folder to non-existent folder Changes: https://git.openjdk.java.net/jdk/pull/4000/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4000&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267043 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4000/head:pull/4000 PR: https://git.openjdk.java.net/jdk/pull/4000 From mcimadamore at openjdk.java.net Wed May 12 17:51:11 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 12 May 2021 17:51:11 GMT Subject: RFR: 8267043: IntelliJ project doesn't handle generated sources correctly [v2] In-Reply-To: References: Message-ID: > Since generated sources are placed in the build folder, and since the build folder is indicated by the IntelliJ project settings as "project output", IntelliJ indexing blissfully ignores all the classes which are generated during the build. > This simple patch fixes that, by simply pointing the project output to a non-existing folder inside the build path (called `idea`). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Bump source level ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4000/files - new: https://git.openjdk.java.net/jdk/pull/4000/files/acb05ab9..cf10eadc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4000&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4000&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4000/head:pull/4000 PR: https://git.openjdk.java.net/jdk/pull/4000 From chegar at openjdk.java.net Wed May 12 18:09:54 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 12 May 2021 18:09:54 GMT Subject: RFR: 8267043: IntelliJ project doesn't handle generated sources correctly [v2] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 17:51:11 GMT, Maurizio Cimadamore wrote: >> Since generated sources are placed in the build folder, and since the build folder is indicated by the IntelliJ project settings as "project output", IntelliJ indexing blissfully ignores all the classes which are generated during the build. >> This simple patch fixes that, by simply pointing the project output to a non-existing folder inside the build path (called `idea`). > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Bump source level Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4000 From erikj at openjdk.java.net Wed May 12 18:33:55 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 12 May 2021 18:33:55 GMT Subject: RFR: 8267043: IntelliJ project doesn't handle generated sources correctly [v2] In-Reply-To: References: Message-ID: On Wed, 12 May 2021 17:51:11 GMT, Maurizio Cimadamore wrote: >> Since generated sources are placed in the build folder, and since the build folder is indicated by the IntelliJ project settings as "project output", IntelliJ indexing blissfully ignores all the classes which are generated during the build. >> This simple patch fixes that, by simply pointing the project output to a non-existing folder inside the build path (called `idea`). > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Bump source level Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4000 From serb at openjdk.java.net Thu May 13 00:47:09 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 13 May 2021 00:47:09 GMT Subject: RFR: 8264846: Regression ~5% in J2dBench.bimg_misc on Linux after JDK-8263142 Message-ID: Performance in one of the tests in the bimg_misc group is dropped by 20%(or 5% of the group) after some unused code was removed from the libawt. I assume the size of the lib became smaller and GCC heuristics were changed to do not try to increase the size by inlining over some percent. I tested various options but most of them affect different test cases in the opposite ways. While testing I have found that the most profitable option is to simply use the "O3" optimization level, moreover, after offline discussion, we have found that this optimization level was used before, but due to the typo, we missed this option and fallback to the "LOW" level. Note this will change optimization level for all platforms in case of any regressions we may try to implement this change for GGC only or we may try to use just these options to solve this performance issue: " -ftree-loop-vectorize -fversion-loops-for-strides " Summary: b12: Number of tests: 13 Overall average: 1222067.1646119351 Best spread: 0.07% variance Worst spread: 3.22% variance (Basis for results comparison) o3: Number of tests: 13 Overall average: 1991716.540920269 Best spread: 0.0% variance Worst spread: 2.22% variance Comparison to basis: Best result: 314.15% of basis Worst result: 97.23% of basis Number of wins: 8 Number of ties: 4 Number of losses: 1 two options: Number of tests: 13 Overall average: 1971528.6542701898 Best spread: 0.0% variance Worst spread: 7.08% variance Comparison to basis: Best result: 312.05% of basis Worst result: 77.27% of basis Number of wins: 6 Number of ties: 1 Number of losses: 6 ------------- Commit messages: - Merge branch 'master' into JDK-8264846 - Merge branch 'master' into JDK-8264846 - Update Awt2dLibraries.gmk - Update Awt2dLibraries.gmk - Merge branch 'master' into JDK-8264846 - Update Awt2dLibraries.gmk Changes: https://git.openjdk.java.net/jdk/pull/3990/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3990&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264846 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3990.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3990/head:pull/3990 PR: https://git.openjdk.java.net/jdk/pull/3990 From joehw at openjdk.java.net Thu May 13 01:17:56 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 13 May 2021 01:17:56 GMT Subject: RFR: 8258795: Update IANA Language Subtag Registry to Version 2021-05-11 In-Reply-To: References: Message-ID: On Wed, 12 May 2021 16:28:54 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3998 From mcimadamore at openjdk.java.net Thu May 13 09:36:15 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 13 May 2021 09:36:15 GMT Subject: Integrated: 8267043: IntelliJ project doesn't handle generated sources correctly In-Reply-To: References: Message-ID: On Wed, 12 May 2021 17:39:26 GMT, Maurizio Cimadamore wrote: > Since generated sources are placed in the build folder, and since the build folder is indicated by the IntelliJ project settings as "project output", IntelliJ indexing blissfully ignores all the classes which are generated during the build. > This simple patch fixes that, by simply pointing the project output to a non-existing folder inside the build path (called `idea`). This pull request has now been integrated. Changeset: a270cbe2 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/a270cbe2ebfe28465b8257f19ff66cf653d21bf4 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8267043: IntelliJ project doesn't handle generated sources correctly Reviewed-by: chegar, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4000 From erikj at openjdk.java.net Thu May 13 12:36:39 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 13 May 2021 12:36:39 GMT Subject: RFR: 8264846: Regression ~5% in J2dBench.bimg_misc on Linux after JDK-8263142 In-Reply-To: References: Message-ID: <79rVRttGoSOnrxCdmb4jdwDTlDWs48bHqottEBZ2pmI=.80afc60d-cb5c-4bb6-b486-fab56a19c2fe@github.com> On Wed, 12 May 2021 00:06:34 GMT, Sergey Bylokhov wrote: > Performance in one of the tests in the bimg_misc group is dropped by 20%(or 5% of the group) after some unused code was removed from the libawt. I assume the size of the lib became smaller and GCC heuristics were changed to do not try to increase the size by inlining over some percent. I tested various options but most of them affect different test cases in the opposite ways. > > While testing I have found that the most profitable option is to simply use the "O3" optimization level, moreover, after offline discussion, we have found that this optimization level was used before, but due to the typo, we missed this option and fallback to the "LOW" level. > > Note this will change optimization level for all platforms in case of any regressions we may try to implement this change for GGC only or we may try to use just these options to solve this performance issue: " -ftree-loop-vectorize -fversion-loops-for-strides " > > > Summary: > b12: > Number of tests: 13 > Overall average: 1222067.1646119351 > Best spread: 0.07% variance > Worst spread: 3.22% variance > (Basis for results comparison) > > o3: > Number of tests: 13 > Overall average: 1991716.540920269 > Best spread: 0.0% variance > Worst spread: 2.22% variance > Comparison to basis: > Best result: 314.15% of basis > Worst result: 97.23% of basis > Number of wins: 8 > Number of ties: 4 > Number of losses: 1 > > two options: > Number of tests: 13 > Overall average: 1971528.6542701898 > Best spread: 0.0% variance > Worst spread: 7.08% variance > Comparison to basis: > Best result: 312.05% of basis > Worst result: 77.27% of basis > Number of wins: 6 > Number of ties: 1 > Number of losses: 6 Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3990 From azvegint at openjdk.java.net Thu May 13 14:15:54 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 13 May 2021 14:15:54 GMT Subject: RFR: 8264846: Regression ~5% in J2dBench.bimg_misc on Linux after JDK-8263142 In-Reply-To: References: Message-ID: <9z6hXv7cqXS3rA40ahLzSWTC2337x17XC454jmEyZgY=.993ee2ab-895b-4cd3-b696-9d656cdbb484@github.com> On Wed, 12 May 2021 00:06:34 GMT, Sergey Bylokhov wrote: > Performance in one of the tests in the bimg_misc group is dropped by 20%(or 5% of the group) after some unused code was removed from the libawt. I assume the size of the lib became smaller and GCC heuristics were changed to do not try to increase the size by inlining over some percent. I tested various options but most of them affect different test cases in the opposite ways. > > While testing I have found that the most profitable option is to simply use the "O3" optimization level, moreover, after offline discussion, we have found that this optimization level was used before, but due to the typo, we missed this option and fallback to the "LOW" level. > > Note this will change optimization level for all platforms in case of any regressions we may try to implement this change for GGC only or we may try to use just these options to solve this performance issue: " -ftree-loop-vectorize -fversion-loops-for-strides " > > > Summary: > b12: > Number of tests: 13 > Overall average: 1222067.1646119351 > Best spread: 0.07% variance > Worst spread: 3.22% variance > (Basis for results comparison) > > o3: > Number of tests: 13 > Overall average: 1991716.540920269 > Best spread: 0.0% variance > Worst spread: 2.22% variance > Comparison to basis: > Best result: 314.15% of basis > Worst result: 97.23% of basis > Number of wins: 8 > Number of ties: 4 > Number of losses: 1 > > two options: > Number of tests: 13 > Overall average: 1971528.6542701898 > Best spread: 0.0% variance > Worst spread: 7.08% variance > Comparison to basis: > Best result: 312.05% of basis > Worst result: 77.27% of basis > Number of wins: 6 > Number of ties: 1 > Number of losses: 6 Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3990 From naoto at openjdk.java.net Thu May 13 16:24:06 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 13 May 2021 16:24:06 GMT Subject: Integrated: 8258795: Update IANA Language Subtag Registry to Version 2021-05-11 In-Reply-To: References: Message-ID: <1le7MjJnN23bmuhXodlfBpp4-TrVPToGaH_537MA3JY=.3b9c8503-23e0-4278-9705-4d747a7d7c21@github.com> On Wed, 12 May 2021 16:28:54 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK. This pull request has now been integrated. Changeset: a259ab4a Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/a259ab4a8d163ff924ba56c5da5395cec0d8c350 Stats: 340 lines in 2 files changed: 327 ins; 0 del; 13 mod 8258795: Update IANA Language Subtag Registry to Version 2021-05-11 Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/3998 From github.com+828220+forax at openjdk.java.net Thu May 13 19:29:38 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 13 May 2021 19:29:38 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 127: > 125: Stream.of(labels).forEach(SwitchBootstraps::verifyLabel); > 126: > 127: return new TypeSwitchCallSite(invocationType, labels); See why below MethodHandle target = MethodHandles.insertArguments(DO_SWITCH, 2, labels); return new ConstantCallsite(target); src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 134: > 132: throw new IllegalArgumentException("null label found"); > 133: } > 134: if (label.getClass() != Class.class && store `label.getClass` in a local variable, it's too bad that you can no use pattern matching here :) src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 141: > 139: } > 140: > 141: static class TypeSwitchCallSite extends ConstantCallSite { That's weird, having a callsite extending MutableCallSite is expected but having a callsite extending constant callsite is useless because you can not change it after being constructed. As an interesting trivia, the VM does not store the CallSite returned by the BSM, but only the target inside it. So there is no point of keeping a ConstantCallSite around. So `doSwitch()` should be static and takes the array of Object[] as parameter, will array will be injected with an insertArguments(). src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 157: > 155: Class targetClass = target.getClass(); > 156: for (int i = startIndex; i < labels.length; i++) { > 157: if (labels[i] instanceof Class) { label[i] should be stored is a local variable and using `instanceof Class c` (like the other instanceof below) will make the code more readable ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From serb at openjdk.java.net Thu May 13 23:45:42 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 13 May 2021 23:45:42 GMT Subject: Integrated: 8264846: Regression ~5% in J2dBench.bimg_misc on Linux after JDK-8263142 In-Reply-To: References: Message-ID: On Wed, 12 May 2021 00:06:34 GMT, Sergey Bylokhov wrote: > Performance in one of the tests in the bimg_misc group is dropped by 20%(or 5% of the group) after some unused code was removed from the libawt. I assume the size of the lib became smaller and GCC heuristics were changed to do not try to increase the size by inlining over some percent. I tested various options but most of them affect different test cases in the opposite ways. > > While testing I have found that the most profitable option is to simply use the "O3" optimization level, moreover, after offline discussion, we have found that this optimization level was used before, but due to the typo, we missed this option and fallback to the "LOW" level. > > Note this will change optimization level for all platforms in case of any regressions we may try to implement this change for GGC only or we may try to use just these options to solve this performance issue: " -ftree-loop-vectorize -fversion-loops-for-strides " > > > Summary: > b12: > Number of tests: 13 > Overall average: 1222067.1646119351 > Best spread: 0.07% variance > Worst spread: 3.22% variance > (Basis for results comparison) > > o3: > Number of tests: 13 > Overall average: 1991716.540920269 > Best spread: 0.0% variance > Worst spread: 2.22% variance > Comparison to basis: > Best result: 314.15% of basis > Worst result: 97.23% of basis > Number of wins: 8 > Number of ties: 4 > Number of losses: 1 > > two options: > Number of tests: 13 > Overall average: 1971528.6542701898 > Best spread: 0.0% variance > Worst spread: 7.08% variance > Comparison to basis: > Best result: 312.05% of basis > Worst result: 77.27% of basis > Number of wins: 6 > Number of ties: 1 > Number of losses: 6 This pull request has now been integrated. Changeset: 40860813 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/408608130621b340151276dceeaf52cf6d037d53 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8264846: Regression ~5% in J2dBench.bimg_misc on Linux after JDK-8263142 Reviewed-by: erikj, azvegint ------------- PR: https://git.openjdk.java.net/jdk/pull/3990 From kvn at openjdk.java.net Fri May 14 17:51:18 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 14 May 2021 17:51:18 GMT Subject: RFR: 8267112: JVMCI compiler modules should be kept upgradable Message-ID: [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes removed sources and also removed JVMCI compiler from list of upgradable modules. JVMCI compiler modules should be upgradable in JDK to work with GraalVM. Make these modules upgradable again and empty by leaving only reference to JVMCI (jdk.internal.vm.ci) module. It does not restore sources - only `module-info.java` files are kept. Note, we continue discussion about [JDK-8265091](https://bugs.openjdk.java.net/browse/JDK-8265091): "Use Module API to export JVMCI packages at runtime" to see if we can remove these `module-info.java` files. Changes were proposed by @dougxc after testing [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes with GraalVM. I restored related code in some tests for them to pass. Testing: full tier1-tier3. ------------- Commit messages: - Fix tests - 8267112: Graal modules should be kept upgradable Changes: https://git.openjdk.java.net/jdk/pull/4014/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4014&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267112 Stats: 83 lines in 9 files changed: 34 ins; 42 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4014.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4014/head:pull/4014 PR: https://git.openjdk.java.net/jdk/pull/4014 From dnsimon at openjdk.java.net Fri May 14 17:51:18 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Fri, 14 May 2021 17:51:18 GMT Subject: RFR: 8267112: JVMCI compiler modules should be kept upgradable In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote: > [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes removed sources and also removed JVMCI compiler from list of upgradable modules. JVMCI compiler modules should be upgradable in JDK to work with GraalVM. > > Make these modules upgradable again and empty by leaving only reference to JVMCI (jdk.internal.vm.ci) module. It does not restore sources - only `module-info.java` files are kept. > > Note, we continue discussion about [JDK-8265091](https://bugs.openjdk.java.net/browse/JDK-8265091): "Use Module API to export JVMCI packages at runtime" to see if we can remove these `module-info.java` files. > > Changes were proposed by @dougxc after testing [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes with GraalVM. > I restored related code in some tests for them to pass. > > Testing: full tier1-tier3. Looks good. My only suggestion would have been to avoid mentioning "Graal" in the PR title and description. This is really about making `jdk.internal.vm.compiler` a placeholder module for any JVMCI based compiler, of which Graal is one example. ------------- PR: https://git.openjdk.java.net/jdk/pull/4014 From mchung at openjdk.java.net Fri May 14 18:09:35 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 14 May 2021 18:09:35 GMT Subject: RFR: 8267112: JVMCI compiler modules should be kept upgradable In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote: > [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes removed sources and also removed JVMCI compiler from list of upgradable modules. JVMCI compiler modules should be upgradable in JDK to work with GraalVM. > > Make these modules upgradable again and empty by leaving only reference to JVMCI (jdk.internal.vm.ci) module. It does not restore sources - only `module-info.java` files are kept. > > Note, we continue discussion about [JDK-8265091](https://bugs.openjdk.java.net/browse/JDK-8265091): "Use Module API to export JVMCI packages at runtime" to see if we can remove these `module-info.java` files. > > Changes were proposed by @dougxc after testing [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes with GraalVM. > I restored related code in some tests for them to pass. > > Testing: full tier1-tier3. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4014 From kvn at openjdk.java.net Fri May 14 19:44:51 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 14 May 2021 19:44:51 GMT Subject: RFR: 8267112: JVMCI compiler modules should be kept upgradable In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote: > [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes removed sources and also removed JVMCI compiler from list of upgradable modules. JVMCI compiler modules should be upgradable in JDK to work with GraalVM. > > Make these modules upgradable again and empty by leaving only reference to JVMCI (jdk.internal.vm.ci) module. It does not restore sources - only `module-info.java` files are kept. > > Note, we continue discussion about [JDK-8265091](https://bugs.openjdk.java.net/browse/JDK-8265091): "Use Module API to export JVMCI packages at runtime" to see if we can remove these `module-info.java` files. > > Changes were proposed by @dougxc after testing [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes with GraalVM. > I restored related code in some tests for them to pass. > > Testing: full tier1-tier3. Thank you, Mandy. ------------- PR: https://git.openjdk.java.net/jdk/pull/4014 From sviswanathan at openjdk.java.net Sat May 15 01:48:35 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Sat, 15 May 2021 01:48:35 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v3] In-Reply-To: References: Message-ID: <2gAn7RV3gzdAOuAZNRcINNLi4NKBwYJW-4NdjcRgpCE=.5e3c0cc3-c89b-486d-8749-cfa630e59f04@github.com> > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge master - Merge master - remove whitespace - Merge master - Small fix - cleanup - x86 short vector math optimization for Vector API ------------- Changes: https://git.openjdk.java.net/jdk/pull/3638/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=02 Stats: 417101 lines in 120 files changed: 416935 ins; 123 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Sat May 15 02:06:29 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Sat, 15 May 2021 02:06:29 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v4] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Add missing Lib.gmk ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/6e105f51..01a549e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=02-03 Stats: 42 lines in 1 file changed: 42 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From erikj at openjdk.java.net Mon May 17 13:03:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 17 May 2021 13:03:42 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v4] In-Reply-To: References: Message-ID: On Sat, 15 May 2021 02:06:29 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Add missing Lib.gmk Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3638 From jiefu at openjdk.java.net Mon May 17 13:31:09 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 17 May 2021 13:31:09 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines Message-ID: Hi all, vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. It would be better to fix it. Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 ------------- Commit messages: - 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines Changes: https://git.openjdk.java.net/jdk/pull/4062/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4062&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267246 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4062.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4062/head:pull/4062 PR: https://git.openjdk.java.net/jdk/pull/4062 From shade at openjdk.java.net Mon May 17 17:00:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 17 May 2021 17:00:00 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines In-Reply-To: References: Message-ID: On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. > > It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 Wait, no. That would mean on large core machines, the sum of heap sizes would be more than physical memory size. That is, 1% multiplied over >100 JTREG_JOBS would be >100%. Since `MaxRAMPercentage` is lower priority than `-Xmx`, and seeing that test does not expect heap OOME, why not just put the explicit heap size in that test? diff --git a/test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java b/test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java index 0d5f1a1626f..4ee794fb79d 100644 --- a/test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java +++ b/test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java @@ -36,7 +36,7 @@ * @build vm.mlvm.anonloader.stress.oome.metaspace.Test * @run driver vm.mlvm.share.IndifiedClassesBuilder * - * @run main/othervm -XX:-UseGCOverheadLimit -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=20m vm.mlvm.anonloader.stress.oome.metaspace.Test + * @run main/othervm -Xmx1g -XX:-UseGCOverheadLimit -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=20m vm.mlvm.anonloader.stress.oome.metaspace.Test */ package vm.mlvm.anonloader.stress.oome.metaspace; ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4062 From shade at openjdk.java.net Mon May 17 17:03:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 17 May 2021 17:03:40 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines In-Reply-To: References: Message-ID: On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. > > It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 ...maybe even `-Xmx512m`, you need to see what works. ------------- PR: https://git.openjdk.java.net/jdk/pull/4062 From naoto at openjdk.java.net Mon May 17 17:08:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 17 May 2021 17:08:30 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current Message-ID: Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. ------------- Commit messages: - Added more ResourceBundleProvider tests - ResourceBundleProvider and test cases modifications - Eliminated some duplicated code - Changed ResourceBundle javadoc - Locale class description - renamed old resource files - inital commit Changes: https://git.openjdk.java.net/jdk/pull/4069/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4069&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263202 Stats: 382 lines in 35 files changed: 239 ins; 41 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/4069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4069/head:pull/4069 PR: https://git.openjdk.java.net/jdk/pull/4069 From erikj at openjdk.java.net Mon May 17 17:14:41 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 17 May 2021 17:14:41 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines In-Reply-To: References: Message-ID: On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. > > It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 The option -XX:MaxRAMPercentage can't really scale up properly unless it accepts values lower than 1. Not sure what to do about this. Even before hitting 0, we get very clunky behavior due to rounding at lower values. ------------- PR: https://git.openjdk.java.net/jdk/pull/4062 From erikj at openjdk.java.net Mon May 17 17:17:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 17 May 2021 17:17:42 GMT Subject: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current In-Reply-To: References: Message-ID: <7AIkJPfmGbs8ZppuRu6kDGP4fZXu_RG9t7KEvPLFaJ8=.43150153-f88a-44bd-a903-fe019e2ab9f9@github.com> On Mon, 17 May 2021 16:55:35 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for compatibility behavior. ResourceBundle class is also modified to load either obsolete/current bundles. For more detail, take a look at the CSR. I see no relevant build changes to comment on as the build label was only added because the buildtool java source was touched, so this looks ok from a build perspective. ------------- PR: https://git.openjdk.java.net/jdk/pull/4069 From shade at openjdk.java.net Mon May 17 17:19:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 17 May 2021 17:19:58 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines In-Reply-To: References: Message-ID: On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. > > It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 `-XX:MaxRAMPercentage` is actually `double`, so it can accept values below 1. The last time I looked into trouble like this, it was a problem with doing floating-point division in the make files -- not sure if something can be done about that. But my point is that the failing test -- is that the only test that fails? -- expects some heap size to accommodate Java allocations until the expected Metaspace OOM happens. In that case, the fix should be in the test itself. Because even if we do +1 to `MaxRAMPercentage`, it might still be not enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/4062 From erik.joelsson at oracle.com Mon May 17 17:30:52 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 17 May 2021 10:30:52 -0700 Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines In-Reply-To: References: Message-ID: <69260c49-3c6c-b4c4-6297-1b68a1c3bf25@oracle.com> On 2021-05-17 10:19, Aleksey Shipilev wrote: > On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote: > >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. >> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. >> >> It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. >> >> Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. >> It would be better to fix it. >> >> Thanks. >> Best regards, >> Jie >> >> >> [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 > `-XX:MaxRAMPercentage` is actually `double`, so it can accept values below 1. The last time I looked into trouble like this, it was a problem with doing floating-point division in the make files -- not sure if something can be done about that. Oh, if it's double, we can just switch to using awk to make the calculation, just like we do for TEST_JOBS. I just did a quick check and it produces float values. > But my point is that the failing test -- is that the only test that fails? -- expects some heap size to accommodate Java allocations until the expected Metaspace OOM happens. In that case, the fix should be in the test itself. Because even if we do +1 to `MaxRAMPercentage`, it might still be not enough. If this test has special needs, those should of course be handled by the test itself. /Erik From shade at redhat.com Mon May 17 17:35:07 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 May 2021 19:35:07 +0200 Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines In-Reply-To: <69260c49-3c6c-b4c4-6297-1b68a1c3bf25@oracle.com> References: <69260c49-3c6c-b4c4-6297-1b68a1c3bf25@oracle.com> Message-ID: <3bb918e2-6b81-87ce-3d7b-87de95a034b9@redhat.com> On 5/17/21 7:30 PM, erik.joelsson at oracle.com wrote: > Oh, if it's double, we can just switch to using awk to make the > calculation, just like we do for TEST_JOBS. I just did a quick check and > it produces float values. Oh, cool. Having a more precise MaxRAMPercentage would be nice. -- Thanks, -Aleksey From jlahoda at openjdk.java.net Mon May 17 19:04:11 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 17 May 2021 19:04:11 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: - Reflecting recent spec changes. - Reflecting review comments. - Reflecting review comments on SwitchBootstraps. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/5e663d70..54ba974e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=00-01 Stats: 544 lines in 18 files changed: 431 ins; 68 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Mon May 17 19:04:11 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 17 May 2021 19:04:11 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 20:48:34 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: >> >> - Reflecting recent spec changes. >> - Reflecting review comments. >> - Reflecting review comments on SwitchBootstraps. > > Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening. > > In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well. @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested changes in recent commits (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 ). I've also tried to update the implementation for the latest spec changes here: https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b The spec changes are: total patterns are nullable; pattern matching ("new") statement switches must be complete (as switch expressions). Any further feedback is welcome! ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From github.com+828220+forax at openjdk.java.net Mon May 17 19:21:41 2021 From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 17 May 2021 19:21:41 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2] In-Reply-To: References: Message-ID: <4O-2pD_4PUl_DRDCLvPO6nNwOvqN-j0GvQzogPTJ0hE=.d5009f6b-72a8-4a96-80b9-4a3a73178e1e@github.com> On Mon, 17 May 2021 19:04:11 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: > > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. It's not clear to me if it's the first change and several will follow or not. The code looks good but the metaprotocol is not the right one IMO, i would prefer the one we discuss in April https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-April/002992.html But this can be tackle in another PR ------------- Marked as reviewed by forax at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/3863 From kvn at openjdk.java.net Mon May 17 19:32:41 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 17 May 2021 19:32:41 GMT Subject: RFR: 8267112: JVMCI compiler modules should be kept upgradable In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote: > [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes removed sources and also removed JVMCI compiler from list of upgradable modules. JVMCI compiler modules should be upgradable in JDK to work with GraalVM. > > Make these modules upgradable again and empty by leaving only reference to JVMCI (jdk.internal.vm.ci) module. It does not restore sources - only `module-info.java` files are kept. > > Note, we continue discussion about [JDK-8265091](https://bugs.openjdk.java.net/browse/JDK-8265091): "Use Module API to export JVMCI packages at runtime" to see if we can remove these `module-info.java` files. > > Changes were proposed by @dougxc after testing [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes with GraalVM. > I restored related code in some tests for them to pass. > > Testing: full tier1-tier3. @erikj79, are you okay with these changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/4014 From erikj at openjdk.java.net Mon May 17 20:13:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 17 May 2021 20:13:42 GMT Subject: RFR: 8267112: JVMCI compiler modules should be kept upgradable In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote: > [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes removed sources and also removed JVMCI compiler from list of upgradable modules. JVMCI compiler modules should be upgradable in JDK to work with GraalVM. > > Make these modules upgradable again and empty by leaving only reference to JVMCI (jdk.internal.vm.ci) module. It does not restore sources - only `module-info.java` files are kept. > > Note, we continue discussion about [JDK-8265091](https://bugs.openjdk.java.net/browse/JDK-8265091): "Use Module API to export JVMCI packages at runtime" to see if we can remove these `module-info.java` files. > > Changes were proposed by @dougxc after testing [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes with GraalVM. > I restored related code in some tests for them to pass. > > Testing: full tier1-tier3. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4014 From kvn at openjdk.java.net Mon May 17 20:13:42 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 17 May 2021 20:13:42 GMT Subject: RFR: 8267112: JVMCI compiler modules should be kept upgradable In-Reply-To: References: Message-ID: On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote: > [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes removed sources and also removed JVMCI compiler from list of upgradable modules. JVMCI compiler modules should be upgradable in JDK to work with GraalVM. > > Make these modules upgradable again and empty by leaving only reference to JVMCI (jdk.internal.vm.ci) module. It does not restore sources - only `module-info.java` files are kept. > > Note, we continue discussion about [JDK-8265091](https://bugs.openjdk.java.net/browse/JDK-8265091): "Use Module API to export JVMCI packages at runtime" to see if we can remove these `module-info.java` files. > > Changes were proposed by @dougxc after testing [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes with GraalVM. > I restored related code in some tests for them to pass. > > Testing: full tier1-tier3. Thank you, Erik. ------------- PR: https://git.openjdk.java.net/jdk/pull/4014 From kvn at openjdk.java.net Mon May 17 20:13:43 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 17 May 2021 20:13:43 GMT Subject: Integrated: 8267112: JVMCI compiler modules should be kept upgradable In-Reply-To: References: Message-ID: <90anbXn1snIdlOvyjnIDTOjLGlJAIpktD336jmT6OjU=.3ac10a6b-20e3-4604-bb18-e00b44a75546@github.com> On Thu, 13 May 2021 16:37:38 GMT, Vladimir Kozlov wrote: > [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes removed sources and also removed JVMCI compiler from list of upgradable modules. JVMCI compiler modules should be upgradable in JDK to work with GraalVM. > > Make these modules upgradable again and empty by leaving only reference to JVMCI (jdk.internal.vm.ci) module. It does not restore sources - only `module-info.java` files are kept. > > Note, we continue discussion about [JDK-8265091](https://bugs.openjdk.java.net/browse/JDK-8265091): "Use Module API to export JVMCI packages at runtime" to see if we can remove these `module-info.java` files. > > Changes were proposed by @dougxc after testing [JDK-8264806](https://bugs.openjdk.java.net/browse/JDK-8264806) changes with GraalVM. > I restored related code in some tests for them to pass. > > Testing: full tier1-tier3. This pull request has now been integrated. Changeset: 2effdd1b Author: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/2effdd1b6799a15a766b2b2a6cba4806d92122f3 Stats: 83 lines in 9 files changed: 34 ins; 42 del; 7 mod 8267112: JVMCI compiler modules should be kept upgradable Reviewed-by: mchung, erikj, dnsimon ------------- PR: https://git.openjdk.java.net/jdk/pull/4014 From weijun at openjdk.java.net Mon May 17 22:01:52 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 17 May 2021 22:01:52 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Message-ID: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). The code change is divided into 3 commits. Please review them one by one. 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. ------------- Commit messages: - add supresswarnings annotations automatically - manual change before automatic annotating - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266459 Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Mon May 17 22:01:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 17 May 2021 22:01:53 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. The 3rd commit is the biggest one but it's all generated programmatically. All changes are simply adding `@SupressWarnings("removal")` to a declaration. Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 + @SuppressWarnings("removal") There are also 7 cases where an existing annotation is updated ================= 2 ==================== - @SuppressWarnings("deprecation") + @SuppressWarnings({"removal","deprecation"}) ================= 1 ==================== - @SuppressWarnings("Convert2Lambda") + @SuppressWarnings({"removal","Convert2Lambda"}) ================= 1 ==================== - @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"}) + @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"}) ================= 1 ==================== - @SuppressWarnings("deprecation") // Use of RMISecurityManager + @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager ================= 1 ==================== - @SuppressWarnings("unchecked") /*To suppress warning from line 1374*/ + @SuppressWarnings({"removal","unchecked"}) /*To suppress warning from line 1374*/ ================= 1 ==================== - @SuppressWarnings("fallthrough") + @SuppressWarnings({"removal","fallthrough"}) All other cases are new annotation embedded inline: ================= 7 ==================== - AccessControlContext acc) { + @SuppressWarnings("removal") AccessControlContext acc) { ================= 4 ==================== - AccessControlContext acc, + @SuppressWarnings("removal") AccessControlContext acc, ================= 3 ==================== - AccessControlContext context, + @SuppressWarnings("removal") AccessControlContext context, ================= 3 ==================== - AccessControlContext acc) + @SuppressWarnings("removal") AccessControlContext acc) ================= 2 ==================== - try (InputStream stream = AccessController.doPrivileged(pa)) { + try (@SuppressWarnings("removal") InputStream stream = AccessController.doPrivileged(pa)) { ================= 2 ==================== - AccessControlContext context, Permission... perms) { + @SuppressWarnings("removal") AccessControlContext context, Permission... perms) { ================= 2 ==================== - } catch (java.security.AccessControlException e) { + } catch (@SuppressWarnings("removal") java.security.AccessControlException e) { ================= 2 ==================== - } catch (AccessControlException ace) { + } catch (@SuppressWarnings("removal") AccessControlException ace) { ================= 2 ==================== - AccessControlContext context) + @SuppressWarnings("removal") AccessControlContext context) ================= 2 ==================== - AccessControlContext acc) throws LoginException { + @SuppressWarnings("removal") AccessControlContext acc) throws LoginException { ================= 2 ==================== - } catch (AccessControlException e) { + } catch (@SuppressWarnings("removal") AccessControlException e) { ================= 1 ==================== - public static void addHook(AccessControlContext acc, PlatformEventType type, Runnable hook) { + public static void addHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) { ================= 1 ==================== - DomainCombiner combiner, + @SuppressWarnings("removal") DomainCombiner combiner, ================= 1 ==================== - } catch (java.security.AccessControlException ace) { + } catch (@SuppressWarnings("removal") java.security.AccessControlException ace) { ================= 1 ==================== - private static File checkFile(File f, SecurityManager sm) { + private static File checkFile(File f, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - private static File checkFile(File file, SecurityManager sm) { + private static File checkFile(File file, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm, + private static void checkPackageAccessForPermittedSubclasses(@SuppressWarnings("removal") SecurityManager sm, ================= 1 ==================== - ProtectionDomain[] getProtectDomains(AccessControlContext context); + ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context); ================= 1 ==================== - SecureCallbackHandler(java.security.AccessControlContext acc, + SecureCallbackHandler(@SuppressWarnings("removal") java.security.AccessControlContext acc, ================= 1 ==================== - private static void addHookInternal(AccessControlContext acc, PlatformEventType type, Runnable hook) { + private static void addHookInternal(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) { ================= 1 ==================== - private void checkMemberAccess(SecurityManager sm, int which, + private void checkMemberAccess(@SuppressWarnings("removal") SecurityManager sm, int which, ================= 1 ==================== - private static File[] checkFiles(Stream filesStream, SecurityManager sm) { + private static File[] checkFiles(Stream filesStream, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - Thread(Runnable target, AccessControlContext acc) { + Thread(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - public ProtectionDomain[] getProtectDomains(AccessControlContext context) { + public ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context) { ================= 1 ==================== - AccessControlContext context); + @SuppressWarnings("removal") AccessControlContext context); ================= 1 ==================== - AccessControlContext stack, - AccessControlContext context); + @SuppressWarnings("removal") AccessControlContext stack, + @SuppressWarnings("removal") AccessControlContext context); ================= 1 ==================== - AccessControlContext(ProtectionDomain caller, DomainCombiner combiner, + AccessControlContext(ProtectionDomain caller, @SuppressWarnings("removal") DomainCombiner combiner, ================= 1 ==================== - public URLClassPath(URL[] urls, AccessControlContext acc) { + public URLClassPath(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - URLClassLoader(URL[] urls, AccessControlContext acc) { + URLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - public static void setSecurityManager(SecurityManager sm) { + public static void setSecurityManager(@SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - try (DataInputStream dis = new DataInputStream(new InflaterInputStream( + try (@SuppressWarnings("removal") DataInputStream dis = new DataInputStream(new InflaterInputStream( ================= 1 ==================== - try (FileInputStream fis = AccessController.doPrivileged( + try (@SuppressWarnings("removal") FileInputStream fis = AccessController.doPrivileged( ================= 1 ==================== - FactoryURLClassLoader(URL[] urls, AccessControlContext acc) { + FactoryURLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - Thread newThreadWithAcc(Runnable target, AccessControlContext acc); + Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc); ================= 1 ==================== - SecureRecorderListener(AccessControlContext context, FlightRecorderListener changeListener) { + SecureRecorderListener(@SuppressWarnings("removal") AccessControlContext context, FlightRecorderListener changeListener) { ================= 1 ==================== - private PolicyDelegate(PolicySpi spi, Provider p, + private PolicyDelegate(@SuppressWarnings("removal") PolicySpi spi, Provider p, ================= 1 ==================== - DomainCombiner combiner) { + @SuppressWarnings("removal") DomainCombiner combiner) { ================= 1 ==================== - PrivilegedRunnable(Runnable r, AccessControlContext acc) { + PrivilegedRunnable(Runnable r, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - private static File[] checkFiles(Stream fs, SecurityManager sm) { + private static File[] checkFiles(Stream fs, @SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - private void checkSpecifyHandler(SecurityManager sm) { + private void checkSpecifyHandler(@SuppressWarnings("removal") SecurityManager sm) { ================= 1 ==================== - String serverPrincipal, AccessControlContext acc) + String serverPrincipal, @SuppressWarnings("removal") AccessControlContext acc) ================= 1 ==================== - public Thread newThreadWithAcc(Runnable target, AccessControlContext acc) { + public Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - try (InputStream is = AccessController.doPrivileged(new PrivilegedAction() { + try (@SuppressWarnings("removal") InputStream is = AccessController.doPrivileged(new PrivilegedAction() { ================= 1 ==================== - public EventFileStream(AccessControlContext acc, Path path) throws IOException { + public EventFileStream(@SuppressWarnings("removal") AccessControlContext acc, Path path) throws IOException { ================= 1 ==================== - AccessControlContext context, Permission... perms) + @SuppressWarnings("removal") AccessControlContext context, Permission... perms) ================= 1 ==================== - private static void privateCheckPackageAccess(SecurityManager s, Class clazz) { + private static void privateCheckPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) { ================= 1 ==================== - AbstractEventStream(AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException { + AbstractEventStream(@SuppressWarnings("removal") AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException { ================= 1 ==================== - private void checkPackageAccess(SecurityManager sm, final ClassLoader ccl, + private void checkPackageAccess(@SuppressWarnings("removal") SecurityManager sm, final ClassLoader ccl, ================= 1 ==================== - AccessControlContext context) { + @SuppressWarnings("removal") AccessControlContext context) { ================= 1 ==================== - public PrivilegedExecutor(Executor executor, AccessControlContext acc) { + public PrivilegedExecutor(Executor executor, @SuppressWarnings("removal") AccessControlContext acc) { ================= 1 ==================== - private RequestHook(AccessControlContext acc, PlatformEventType eventType, Runnable hook) { + private RequestHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType eventType, Runnable hook) { ================= 1 ==================== - try (BufferedReader bufferedReader = + try (@SuppressWarnings("removal") BufferedReader bufferedReader = ================= 1 ==================== - private static void privateCheckProxyPackageAccess(SecurityManager s, Class clazz) { + private static void privateCheckProxyPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) { **That's all**. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From kvn at openjdk.java.net Mon May 17 22:20:44 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 17 May 2021 22:20:44 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v4] In-Reply-To: References: Message-ID: On Sat, 15 May 2021 02:06:29 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Add missing Lib.gmk I reviewed only HotSpot part. Main complain is long list of library entry points (vector functions) repeated in several files. May be use macros/lambdas? with loops to reduce number of lines and consolidate in one place. Add comments explaining numbers and letters in names. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7290: > 7288: StubRoutines::_vector_cbrt_float128 = (address)os::dll_lookup(libsvml, "__svml_cbrtf4_ha_ex"); > 7289: StubRoutines::_vector_cbrt_double64 = (address)os::dll_lookup(libsvml, "__svml_cbrt1_ha_ex"); > 7290: StubRoutines::_vector_cbrt_double128 = (address)os::dll_lookup(libsvml, "__svml_cbrt2_ha_ex"); May be use macros with **comments**? In this code is very easy make `copy-paste` errors. And It is very not clear for me what all these numbers and letters mean in names. I can guess but it should be comments. src/hotspot/cpu/x86/x86_64.ad line 1713: > 1711: return OptoRegPair(hi, lo); > 1712: } > 1713: Should these methods check `EnableVectorSupport` flag too? Or `UseVectorStubs`? src/hotspot/share/opto/callnode.cpp line 747: > 745: > 746: // If the return is in vector, compute appropriate regmask taking into account the whole range > 747: if(ideal_reg >= Op_VecS && ideal_reg <= Op_VecZ) { Should this be done only for CallLeafVector? Can `Valhalla` return big object in one of vector registers? src/hotspot/share/opto/vectorIntrinsics.cpp line 353: > 351: if (operation == NULL) { > 352: if (C->print_intrinsics()) { > 353: tty->print_cr(" ** svml call failed"); Also print information about the call which fail. src/hotspot/share/opto/vectorIntrinsics.cpp line 1682: > 1680: default: Unimplemented(); break; > 1681: } > 1682: } Macros? src/hotspot/share/runtime/stubRoutines.cpp line 330: > 328: address StubRoutines::_vector_atan2_double256 = NULL; > 329: address StubRoutines::_vector_atan2_double512 = NULL; > 330: #endif // __VECTOR_API_MATH_INTRINSICS_COMMON Macros? ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3638 From erikj at openjdk.java.net Mon May 17 22:30:56 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 17 May 2021 22:30:56 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Makefile change looks ok. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From jiefu at openjdk.java.net Mon May 17 23:37:40 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 17 May 2021 23:37:40 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines In-Reply-To: References: Message-ID: On Mon, 17 May 2021 17:17:00 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. >> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. >> >> It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. >> >> Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. >> It would be better to fix it. >> >> Thanks. >> Best regards, >> Jie >> >> >> [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 > > `-XX:MaxRAMPercentage` is actually `double`, so it can accept values below 1. The last time I looked into trouble like this, it was a problem with doing floating-point division in the make files -- not sure if something can be done about that. > > But my point is that the failing test -- is that the only test that fails? -- expects some heap size to accommodate Java allocations until the expected Metaspace OOM happens. In that case, the fix should be in the test itself. Because even if we do +1 to `MaxRAMPercentage`, it might still be not enough. Thanks @shipilev and @erikj79 for your review and nice suggestions. I filed JDK-8267293 to handle the test failure and will fix the unreasonable setting of MaxRAMPercentage in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4062 From jiefu at openjdk.java.net Tue May 18 03:35:11 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 18 May 2021 03:35:11 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines [v2] In-Reply-To: References: Message-ID: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. > > It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Use awk to compute MaxRAMPercentage ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4062/files - new: https://git.openjdk.java.net/jdk/pull/4062/files/94aac13b..a1e7aea9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4062&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4062&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4062.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4062/head:pull/4062 PR: https://git.openjdk.java.net/jdk/pull/4062 From jiefu at openjdk.java.net Tue May 18 03:35:11 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 18 May 2021 03:35:11 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines In-Reply-To: References: Message-ID: On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. > > It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 > _Mailing list message from [Aleksey Shipilev](mailto:shade at redhat.com) on [build-dev](mailto:build-dev at mail.openjdk.java.net):_ > > On 5/17/21 7:30 PM, erik.joelsson at oracle.com wrote: > > > Oh, if it's double, we can just switch to using awk to make the > > calculation, just like we do for TEST_JOBS. I just did a quick check and > > it produces float values. > > Oh, cool. Having a more precise MaxRAMPercentage would be nice. > > -- > Thanks, > -Aleksey Hi @erikj79 and @shipilev , Patch has been updated to using awk to make the calculation. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4062 From alanb at openjdk.java.net Tue May 18 06:33:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 06:33:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. src/java.base/share/classes/java/lang/SecurityManager.java line 315: > 313: * > 314: * @since 1.0 > 315: * @deprecated The Security Manager is deprecated and subject to removal in a Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From shade at openjdk.java.net Tue May 18 07:58:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 18 May 2021 07:58:40 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 03:35:11 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. >> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. >> >> It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. >> >> Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. >> It would be better to fix it. >> >> Thanks. >> Best regards, >> Jie >> >> >> [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Use awk to compute MaxRAMPercentage I am good with this change, but someone else should take a look as well. I ran `tier1` and `tier2` on my 3970X, which usually runs with `-XX:MaxRAMPercentage=0` due to having 32 cores, and the tests completed fine. It now runs with `-XX:MaxRAMPercentage=0.78125`. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4062 From jlahoda at openjdk.java.net Tue May 18 10:00:10 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 18 May 2021 10:00:10 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v3] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/54ba974e..5fa8005a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=01-02 Stats: 22 lines in 2 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From mcimadamore at openjdk.java.net Tue May 18 11:15:51 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 18 May 2021 11:15:51 GMT Subject: RFR: 8267312: Resolve should use generated diagnostic factories Message-ID: This patch allows Resolve to use more static diagnostic factories. Resolution errors support generation of diagnostics. This generation is very flexible and allows creating either a toplevel (error or warning) diagnostic, or a nested (fragment) diagostic. To support this, many resolution diagnostics in javac define some "overloads" in compiler.properties - e.g. # 0: message segment compiler.err.prob.found.req=... # 0: message segment compiler.misc.prob.found.req=... # 0: message segment, 1: type, 2: type compiler.warn.prob.found.req=... To support switching from one diagnostic kind to another, this patch adds a new method on `DiagnosticInfo`, namely `toType(DiagnosticType)`. The default implementation of this method will simply check that the type is identical to that of the current diagnostic info, and throw otherwise. This patch modifies the build-time step to construct diagnostic factories, so that, whenever a diagnostic overload is detected, the `toType` method is overridden, and the right constants/factories are returned/called depending on the requested diagnostic type. For instance, the factory for the `prob.found.req` key will look as follows in the generated code: /** * compiler.err.prob.found.req=\ * incompatible types: {0} */ public static Error ProbFoundReq(Fragment arg0) { return new Error("compiler", "prob.found.req", arg0) { public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) { return switch (kind) { case ERROR -> this; case WARNING -> throw new AssertionError("Unsupported kind: " + kind); case FRAGMENT -> Fragments.ProbFoundReq(arg0); case NOTE -> throw new AssertionError("Unsupported kind: " + kind); }; } }; } As you can see, the build time process correctly detects all diagnostic overloads and generate some code to convert one diagnostic info to another. Note that in this case, only two overloads are detected (`err` and `misc`), given that `warn` has a different type comment so not, technically speaking, an overload. With this support it is relatively easy to go back to Resolve and update most of the resolution errors to use the generated factories. The only case I have not dealt with is the "cannot.resolve" diagnostic, which has many variants: `{ var, method, generic method } x { location, no location }`. To use the factories effectively here a change in the way the diagnostic is structured is required, but doing so, while trivial, will cause many change in the golden test files, so I held off these changes for now, and will come back later to this. ------------- Commit messages: - Add newlines after factory method/field declaration - Simplify code in Resolve - Tweak ClassGenerator - Merge branch 'master' into resolve_error_diags - Polish properties generation code - Kind of works - Sharpen signature of compiler.properties - Initial cleanup; some issues: Changes: https://git.openjdk.java.net/jdk/pull/4089/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4089&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267312 Stats: 248 lines in 6 files changed: 109 ins; 37 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/4089.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4089/head:pull/4089 PR: https://git.openjdk.java.net/jdk/pull/4089 From mcimadamore at openjdk.java.net Tue May 18 12:22:51 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 18 May 2021 12:22:51 GMT Subject: RFR: 8267312: Resolve should use generated diagnostic factories In-Reply-To: References: Message-ID: <-wUi6zR9vjizDIttawHUOORW3tLmbZFc7Idx1A3Favs=.f0771ae2-3aa1-4536-b5d4-8e66b8d230ba@github.com> On Tue, 18 May 2021 11:07:18 GMT, Maurizio Cimadamore wrote: > This patch allows Resolve to use more static diagnostic factories. Resolution errors support generation of diagnostics. This generation is very flexible and allows creating either a toplevel (error or warning) diagnostic, or a nested (fragment) diagostic. To support this, many resolution diagnostics in javac define some "overloads" in compiler.properties - e.g. > > > # 0: message segment > compiler.err.prob.found.req=... > # 0: message segment > compiler.misc.prob.found.req=... > # 0: message segment, 1: type, 2: type > compiler.warn.prob.found.req=... > > > To support switching from one diagnostic kind to another, this patch adds a new method on `DiagnosticInfo`, namely `toType(DiagnosticType)`. The default implementation of this method will simply check that the type is identical to that of the current diagnostic info, and throw otherwise. > > This patch modifies the build-time step to construct diagnostic factories, so that, whenever a diagnostic overload is detected, the `toType` method is overridden, and the right constants/factories are returned/called depending on the requested diagnostic type. For instance, the factory for the `prob.found.req` key will look as follows in the generated code: > > > /** > * compiler.err.prob.found.req=\ > * incompatible types: {0} > */ > public static Error ProbFoundReq(Fragment arg0) { > return new Error("compiler", "prob.found.req", arg0) { > public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) { > return switch (kind) { > case ERROR -> this; > case WARNING -> throw new AssertionError("Unsupported kind: " + kind); > case FRAGMENT -> Fragments.ProbFoundReq(arg0); > case NOTE -> throw new AssertionError("Unsupported kind: " + kind); > }; > } > }; > } > > > As you can see, the build time process correctly detects all diagnostic overloads and generate some code to convert one diagnostic info to another. Note that in this case, only two overloads are detected (`err` and `misc`), given that `warn` has a different type comment so not, technically speaking, an overload. > > With this support it is relatively easy to go back to Resolve and update most of the resolution errors to use the generated factories. > > The only case I have not dealt with is the "cannot.resolve" diagnostic, which has many variants: `{ var, method, generic method } x { location, no location }`. To use the factories effectively here a change in the way the diagnostic is structured is required, but doing so, while trivial, will cause many change in the golden test files, so I held off these changes for now, and will come back later to this. make/langtools/tools/propertiesparser/resources/templates.properties line 53: > 51: {0}public static {1} {2}({3}) '{'\n\ > 52: {4}\n\ > 53: '}\n' This could probably just use text blocks and replacements - I'll leave that for another day. ------------- PR: https://git.openjdk.java.net/jdk/pull/4089 From mullan at openjdk.java.net Tue May 18 12:44:48 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 18 May 2021 12:44:48 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > src/java.base/share/classes/java/lang/SecurityManager.java line 315: > >> 313: * >> 314: * @since 1.0 >> 315: * @deprecated The Security Manager is deprecated and subject to removal in a > > Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check? It includes both: ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg) ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From alanb at openjdk.java.net Tue May 18 15:22:42 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 15:22:42 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 315: >> >>> 313: * >>> 314: * @since 1.0 >>> 315: * @deprecated The Security Manager is deprecated and subject to removal in a >> >> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check? > > It includes both: > ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg) Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mullan at openjdk.java.net Tue May 18 15:49:38 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 18 May 2021 15:49:38 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <0_9OMaDXfGSSqm5VdlusV4KRWnHxD2KFD5ifyV1hVFI=.1ba2b000-954e-4b23-a869-7d3aa1a909d6@github.com> On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman wrote: >> It includes both: >> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg) > > Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence. My feeling is that it is better to be more specific than the generic removal text as this is the most significant class that is being deprecated for removal. Also, this says "the Security Manager" (note the space between) which really encompasses more than the `java.lang.SecurityManager` API and which is explained more completely in the JEP. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Tue May 18 16:03:59 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 18 May 2021 16:03:59 GMT Subject: RFR: 8256372: [macos] Unexpected symbol was displayed on JTextField with Monospaced font Message-ID: See the bug report for lots of explanation. The short version (not that short) is that Swing adds a new line char to editable TextComponents It used to work because harfbuzz asked CoreText which mapped it to an invisible glyph Now harfbuzz does its own processing of AAT fonts it is different. Harfbuzz looks up the mapping for this but there is none so it gets a missing glyph. Solution: Since HB now does AAT processing we can dispense with all the special handling of that case and core text and just treat AAT fonts like OT fonts. This means its gets the same mapping we get when not using Layout. And the test passes on all platforms .. not just macOS .. ------------- Commit messages: - 8256372: [macos] Unexpected symbol was displayed on JTextField with Monospaced font Changes: https://git.openjdk.java.net/jdk/pull/4097/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4097&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256372 Stats: 1425 lines in 9 files changed: 65 ins; 1352 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4097.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4097/head:pull/4097 PR: https://git.openjdk.java.net/jdk/pull/4097 From erikj at openjdk.java.net Tue May 18 16:15:39 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 18 May 2021 16:15:39 GMT Subject: RFR: 8256372: [macos] Unexpected symbol was displayed on JTextField with Monospaced font In-Reply-To: References: Message-ID: On Tue, 18 May 2021 15:55:09 GMT, Phil Race wrote: > See the bug report for lots of explanation. > The short version (not that short) is that Swing adds a new line char to editable TextComponents > It used to work because harfbuzz asked CoreText which mapped it to an invisible glyph > Now harfbuzz does its own processing of AAT fonts it is different. > Harfbuzz looks up the mapping for this but there is none so it gets a missing glyph. > > Solution: Since HB now does AAT processing we can dispense with all the special handling of that case > and core text and just treat AAT fonts like OT fonts. > This means its gets the same mapping we get when not using Layout. > > And the test passes on all platforms .. not just macOS .. Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4097 From erikj at openjdk.java.net Tue May 18 16:22:39 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 18 May 2021 16:22:39 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines [v2] In-Reply-To: References: Message-ID: <-_PBZqAh2dx3sGpmMup_DW0dXnsMEUhtyyeD3Cq0Wxg=.ff248f55-7722-47e2-8e49-f9d6388f2137@github.com> On Tue, 18 May 2021 03:35:11 GMT, Jie Fu wrote: >> Hi all, >> >> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. >> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. >> >> It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. >> >> Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. >> It would be better to fix it. >> >> Thanks. >> Best regards, >> Jie >> >> >> [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Use awk to compute MaxRAMPercentage Looks good to me, thanks for fixing this! I took the change for a spin internally running our tier1-3. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4062 From darcy at openjdk.java.net Tue May 18 16:29:47 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 18 May 2021 16:29:47 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From chegar at openjdk.java.net Tue May 18 16:38:42 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 18 May 2021 16:38:42 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. The changes in the net area look fine. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From naoto at openjdk.java.net Tue May 18 16:45:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 18 May 2021 16:45:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Reviewed i18n/java.time/charset. They all look good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From joehw at openjdk.java.net Tue May 18 17:30:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 18 May 2021 17:30:39 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. java.xml changes look good. Thanks. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073 From alanb at openjdk.java.net Tue May 18 17:39:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 18 May 2021 17:39:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/security/AccessController.java line 877: > 875: @CallerSensitive > 876: public static T doPrivileged(PrivilegedExceptionAction action, > 877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mchung at openjdk.java.net Tue May 18 17:53:51 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 18 May 2021 17:53:51 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Tue May 18 18:42:26 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 18:42:26 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > src/java.base/share/classes/java/security/AccessController.java line 877: > >> 875: @CallerSensitive >> 876: public static T doPrivileged(PrivilegedExceptionAction action, >> 877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) > > you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens. My rule is that a new line is added if there's only whitespaces before the insert position and the previous line does not end with a comma. In this case, unless I move `Permission... perms` onto a new line that an annotation on a new line looks like covering both `context` and `perms`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From serb at openjdk.java.net Tue May 18 19:56:41 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 18 May 2021 19:56:41 GMT Subject: RFR: 8256372: [macos] Unexpected symbol was displayed on JTextField with Monospaced font In-Reply-To: References: Message-ID: On Tue, 18 May 2021 15:55:09 GMT, Phil Race wrote: > See the bug report for lots of explanation. > The short version (not that short) is that Swing adds a new line char to editable TextComponents > It used to work because harfbuzz asked CoreText which mapped it to an invisible glyph > Now harfbuzz does its own processing of AAT fonts it is different. > Harfbuzz looks up the mapping for this but there is none so it gets a missing glyph. > > Solution: Since HB now does AAT processing we can dispense with all the special handling of that case > and core text and just treat AAT fonts like OT fonts. > This means its gets the same mapping we get when not using Layout. > > And the test passes on all platforms .. not just macOS .. src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 1: > 1: /* How we will track these files for the next HB update? Do we need to document it somehow? otherwise, I think it will be added again as a new files. ------------- PR: https://git.openjdk.java.net/jdk/pull/4097 From weijun at openjdk.java.net Tue May 18 21:13:40 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 21:13:40 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang wrote: >> src/java.base/share/classes/java/security/AccessController.java line 877: >> >>> 875: @CallerSensitive >>> 876: public static T doPrivileged(PrivilegedExceptionAction action, >>> 877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) >> >> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens. > > I'll try to update my auto-annotating program. Turns out this only happens in this class: $ rg '^\s*@SuppressWarnings("removal").*?,.' src/java.base/share/classes/java/security/AccessController.java:449: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) { src/java.base/share/classes/java/security/AccessController.java:514: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) { src/java.base/share/classes/java/security/AccessController.java:877: @SuppressWarnings("removal") AccessControlContext context, Permission... perms) I'll fix them manually. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Tue May 18 21:21:45 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 18 May 2021 21:21:45 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v2] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: feedback from Sean, Phil and Alan ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00-01 Stats: 9 lines in 3 files changed: 4 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From sviswanathan at openjdk.java.net Tue May 18 23:27:13 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 18 May 2021 23:27:13 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v5] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Implement review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/01a549e4..9021a15c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=03-04 Stats: 1220 lines in 8 files changed: 48 ins; 1104 del; 68 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Tue May 18 23:43:13 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 18 May 2021 23:43:13 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v6] In-Reply-To: References: Message-ID: <6cWkz6rWmKC0L2U3sYiELeoOphNGlEHvCoSXcJHE-hE=.04e407ec-be8f-4d01-b527-ec7e1d30bb34@github.com> > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Print intrinsic fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/9021a15c..11528426 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=04-05 Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From jiefu at openjdk.java.net Tue May 18 23:56:40 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 18 May 2021 23:56:40 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 07:54:52 GMT, Aleksey Shipilev wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Use awk to compute MaxRAMPercentage > > I ran `tier1` and `tier2` on my 3970X, which usually runs with `-XX:MaxRAMPercentage=0` due to having 32 cores, and the tests completed fine. It now runs with `-XX:MaxRAMPercentage=0.78125`. Thanks @shipilev and @erikj79 for your review. I'll push it tomorrow since JDK-8267293 and JDK-8267311 are easier to be reproduced with the original code. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4062 From sviswanathan at openjdk.java.net Tue May 18 23:59:30 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 18 May 2021 23:59:30 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v6] In-Reply-To: <6cWkz6rWmKC0L2U3sYiELeoOphNGlEHvCoSXcJHE-hE=.04e407ec-be8f-4d01-b527-ec7e1d30bb34@github.com> References: <6cWkz6rWmKC0L2U3sYiELeoOphNGlEHvCoSXcJHE-hE=.04e407ec-be8f-4d01-b527-ec7e1d30bb34@github.com> Message-ID: On Tue, 18 May 2021 23:43:13 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Print intrinsic fix @vnlozlov I have implemented all the review comments. Please let me know if the changes look ok to you. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Tue May 18 23:59:28 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 18 May 2021 23:59:28 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v7] In-Reply-To: References: Message-ID: <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com> > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: jcheck fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/11528426..0d1d0382 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=05-06 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From kvn at openjdk.java.net Wed May 19 00:30:42 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 19 May 2021 00:30:42 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v7] In-Reply-To: <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com> References: <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com> Message-ID: <-BR26RrPjxCrCj3TmA4xRVCvZxEk8njxsQh7kqjmmts=.df6b4208-d5a1-4d28-802b-1fa28848abce@github.com> On Tue, 18 May 2021 23:59:28 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > jcheck fixes This is much much better! Thank you for changing it. I am only asking now to add comment explaining names. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6975: > 6973: if (libsvml != NULL) { > 6974: log_info(library)("Loaded library %s, handle " INTPTR_FORMAT, JNI_LIB_PREFIX "svml" JNI_LIB_SUFFIX, p2i(libsvml)); > 6975: if (UseAVX > 2) { Please add comment here explaining naming convention you are using here. What `f16_ha_z0` mean? Why `8_ha_z0` and not `d8_ha_z0`? What is `l9`, `e9`, `ex`? ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Wed May 19 00:58:15 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 00:58:15 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v8] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Add comments explaining naming convention ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/0d1d0382..45f20a34 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=06-07 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Wed May 19 00:58:18 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 00:58:18 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v7] In-Reply-To: <-BR26RrPjxCrCj3TmA4xRVCvZxEk8njxsQh7kqjmmts=.df6b4208-d5a1-4d28-802b-1fa28848abce@github.com> References: <8FlPfGWCt4m3-JqK3IimdEyhG767zaov3nfteXioR0c=.8e49bf89-d74a-474b-9bd0-cce80f744af3@github.com> <-BR26RrPjxCrCj3TmA4xRVCvZxEk8njxsQh7kqjmmts=.df6b4208-d5a1-4d28-802b-1fa28848abce@github.com> Message-ID: On Wed, 19 May 2021 00:26:48 GMT, Vladimir Kozlov wrote: >> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: >> >> jcheck fixes > > This is much much better! Thank you for changing it. I am only asking now to add comment explaining names. @vnkozlov I have added comments explaining naming convention. Please let me know if this looks ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From kvn at openjdk.java.net Wed May 19 01:07:42 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 19 May 2021 01:07:42 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v8] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 00:58:15 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Add comments explaining naming convention Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Wed May 19 01:31:40 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 01:31:40 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v8] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 00:58:15 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Add comments explaining naming convention Thanks a lot Vladimir! ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From jiefu at openjdk.java.net Wed May 19 01:51:41 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 01:51:41 GMT Subject: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines [v2] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 23:53:51 GMT, Jie Fu wrote: > I'll push it tomorrow since JDK-8267293 and JDK-8267311 are easier to be reproduced with the original code. We can still easily reproduce JDK-8267311 as before with this patch. So push it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4062 From jiefu at openjdk.java.net Wed May 19 01:51:43 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 19 May 2021 01:51:43 GMT Subject: Integrated: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines In-Reply-To: References: Message-ID: On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote: > Hi all, > > vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our many-core machines due to `-XX:MaxRAMPercentage=0`. > This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1]. > > It can be reproduced by: `make test TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java" JTREG="JOBS=26"` on almost all machines. > > Setting `-XX:MaxRAMPercentage=0` on many-core machines seems unreasonable. > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741 This pull request has now been integrated. Changeset: 0daec497 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/0daec497fea8c048a9455e4ff331a9d8c4293a4b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines Reviewed-by: shade, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4062 From sviswanathan at openjdk.java.net Wed May 19 03:37:11 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 03:37:11 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v9] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: fix 32-bit build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/45f20a34..f7e39913 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From jlahoda at openjdk.java.net Wed May 19 08:00:12 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 19 May 2021 08:00:12 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing various error-related bugs. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/5fa8005a..0875377b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=02-03 Stats: 117 lines in 6 files changed: 94 ins; 13 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From vlivanov at openjdk.java.net Wed May 19 08:10:43 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 19 May 2021 08:10:43 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v9] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > fix 32-bit build Overall, looks fine. src/hotspot/cpu/x86/x86_64.ad line 1704: > 1702: } > 1703: > 1704: void Matcher::vector_calling_convention(VMRegPair *regs, uint num_bits, uint total_args_passed) { You can just remove `Matcher::vector_calling_convention()` and call `SharedRuntime::vector_calling_convention()` directly. src/hotspot/share/opto/matcher.cpp line 1370: > 1368: VMReg first = parm_regs[i].first(); > 1369: VMReg second = parm_regs[i].second(); > 1370: if( !first->is_valid() && Please, fix formatting. src/hotspot/share/opto/vectorIntrinsics.cpp line 1355: > 1353: > 1354: // Get address for svml method. > 1355: get_svml_address(vector_api_op_id, vt->length_in_bytes() * BitsPerByte, bt, name, 100, &addr); Any particular reason to return the address as an out argument and not directly (`address addr = get_svml_address(...)`)? src/hotspot/share/utilities/globalDefinitions_vecApi.hpp line 34: > 32: // VS2017 required to build .s files for math intrinsics > 33: #if defined(_WIN64) && (defined(_MSC_VER) && (_MSC_VER >= 1910)) > 34: #define __VECTOR_API_MATH_INTRINSICS_COMMON Considering the stubs are not part of JVM anymore, the macros can go away. The stubs are dynamically linked now and if there's no library built/present the linking will fail. And then `globalDefinitions_vecApi.hpp` becomes empty and can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From weijun at openjdk.java.net Wed May 19 13:47:54 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 13:47:54 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v2] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <8mVaKSBeyfyVBHsp67PuOC1G7--flmHQzygrQTyrgGE=.ed4f6dd9-e0af-4058-97f5-cf5ab3651aa4@github.com> On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > feedback from Sean, Phil and Alan A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` test in tier4. The test compares stderr output with a known value but we have a new warning written to stderr now. It's now using stdout instead. @prrace, Please confirm this is acceptable. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed May 19 13:47:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 13:47:53 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Wed May 19 18:16:57 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 18:16:57 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59: > 57: ProcessCommunicator > 58: .executeChildProcess(Consumer.class, new String[0]); > 59: if (!"Hello".equals(processResults.getStdOut())) { Who or what prompted this change ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Wed May 19 18:19:49 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 18:19:49 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java This change is so large that github won't even display the list of files so I can't jump to where I want to go ! And when I try to scroll I get just a blank page. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Wed May 19 18:29:41 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 18:29:41 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java src/java.desktop/share/classes/java/awt/Component.java line 217: > 215: * @author Sami Shaio > 216: */ > 217: @SuppressWarnings("removal") Why is this placed on the *entire class* ?? This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext. src/java.desktop/share/classes/java/awt/Container.java line 97: > 95: * @since 1.0 > 96: */ > 97: @SuppressWarnings("removal") Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places. Where else are you adding this to entire classes instead of the specific site ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed May 19 18:41:44 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 18:41:44 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 18:26:25 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > > src/java.desktop/share/classes/java/awt/Component.java line 217: > >> 215: * @author Sami Shaio >> 216: */ >> 217: @SuppressWarnings("removal") > > Why is this placed on the *entire class* ?? > This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext. This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is s = java.security.AccessController.doPrivileged( new GetPropertyAction("awt.image.redrawrate")); > src/java.desktop/share/classes/java/awt/Container.java line 97: > >> 95: * @since 1.0 >> 96: */ >> 97: @SuppressWarnings("removal") > > Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places. > > Where else are you adding this to entire classes instead of the specific site ? Similar as the one above, it's because of static { // Don't lazy-read because every app uses invalidate() isJavaAwtSmartInvalidate = AccessController.doPrivileged( new GetBooleanAction("java.awt.smartInvalidate")); } > test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59: > >> 57: ProcessCommunicator >> 58: .executeChildProcess(Consumer.class, new String[0]); >> 59: if (!"Hello".equals(processResults.getStdOut())) { > > Who or what prompted this change ? The child process is started with `-Djava.security.manager=allow` (after the other PR) and a warning will be printed to stderr. Therefore I move the message to stdout. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed May 19 18:46:46 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 18:46:46 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang wrote: >> src/java.desktop/share/classes/java/awt/Container.java line 97: >> >>> 95: * @since 1.0 >>> 96: */ >>> 97: @SuppressWarnings("removal") >> >> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places. >> >> Where else are you adding this to entire classes instead of the specific site ? > > Similar as the one above, it's because of > > static { > // Don't lazy-read because every app uses invalidate() > isJavaAwtSmartInvalidate = AccessController.doPrivileged( > new GetBooleanAction("java.awt.smartInvalidate")); > } We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed May 19 18:51:43 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 18:51:43 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang wrote: >> Similar as the one above, it's because of >> >> static { >> // Don't lazy-read because every app uses invalidate() >> isJavaAwtSmartInvalidate = AccessController.doPrivileged( >> new GetBooleanAction("java.awt.smartInvalidate")); >> } > > We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing. I know it's not easy to read the commit and that's why I make the 3rd commit totally automatic. Hopefully you have more confidence on the program than my hand. All annotations are added to the nearest declarations. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From psandoz at openjdk.java.net Wed May 19 19:26:44 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 19 May 2021 19:26:44 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v9] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > fix 32-bit build src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 723: > 721: #end[BITWISE] > 722: #if[FP] > 723: case VECTOR_OP_OR: return (v0, v1) -> `VECTOR_OP_OR` looks incorrect, since `VectorOperators.OR` is not applicable to FP types. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From prr at openjdk.java.net Wed May 19 19:34:48 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 19:34:48 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang wrote: >> src/java.desktop/share/classes/java/awt/Component.java line 217: >> >>> 215: * @author Sami Shaio >>> 216: */ >>> 217: @SuppressWarnings("removal") >> >> Why is this placed on the *entire class* ?? >> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext. > > This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is > > s = java.security.AccessController.doPrivileged( > new GetPropertyAction("awt.image.redrawrate")); That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable. You can define a static private method to contain this and call it from the static initializer block. Much better than applying the annotation to an entire class. --- a/src/java.desktop/share/classes/java/awt/Component.java +++ b/src/java.desktop/share/classes/java/awt/Component.java @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer, */ static boolean isInc; static int incRate; + + private static void initIncRate() { + String s = java.security.AccessController.doPrivileged( + new GetPropertyAction("awt.image.incrementaldraw")); + isInc = (s == null || s.equals("true")); + + s = java.security.AccessController.doPrivileged( + new GetPropertyAction("awt.image.redrawrate")); + incRate = (s != null) ? Integer.parseInt(s) : 100; + } + static { /* ensure that the necessary native libraries are loaded */ Toolkit.loadLibraries(); @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer, if (!GraphicsEnvironment.isHeadless()) { initIDs(); } - - String s = java.security.AccessController.doPrivileged( - new GetPropertyAction("awt.image.incrementaldraw")); - isInc = (s == null || s.equals("true")); - - s = java.security.AccessController.doPrivileged( - new GetPropertyAction("awt.image.redrawrate")); - incRate = (s != null) ? Integer.parseInt(s) : 100; + initIncRate(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From vromero at openjdk.java.net Wed May 19 20:46:23 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 19 May 2021 20:46:23 GMT Subject: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v8] In-Reply-To: References: Message-ID: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - restoring jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES, it is needed by the build - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - updating comment after review feedback - removing javax.lang.model changes - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - ... and 2 more: https://git.openjdk.java.net/jdk/compare/cc4f43fb...d220bc20 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3526/files - new: https://git.openjdk.java.net/jdk/pull/3526/files/0208dcf0..d220bc20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=06-07 Stats: 40144 lines in 1123 files changed: 19391 ins; 13080 del; 7673 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526 From sviswanathan at openjdk.java.net Wed May 19 21:55:07 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 21:55:07 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v10] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Implement Vladimir Ivanov and Paul Sandoz review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/f7e39913..0b4a1c9c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=08-09 Stats: 45 lines in 1 file changed: 0 ins; 45 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From weijun at openjdk.java.net Wed May 19 21:56:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 21:56:30 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> Message-ID: On Wed, 19 May 2021 19:31:24 GMT, Phil Race wrote: >> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is >> >> s = java.security.AccessController.doPrivileged( >> new GetPropertyAction("awt.image.redrawrate")); > > That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable. > You can define a static private method to contain this and call it from the static initializer block. > Much better than applying the annotation to an entire class. > > --- a/src/java.desktop/share/classes/java/awt/Component.java > +++ b/src/java.desktop/share/classes/java/awt/Component.java > @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer, > */ > static boolean isInc; > static int incRate; > + > + private static void initIncRate() { > + String s = java.security.AccessController.doPrivileged( > + new GetPropertyAction("awt.image.incrementaldraw")); > + isInc = (s == null || s.equals("true")); > + > + s = java.security.AccessController.doPrivileged( > + new GetPropertyAction("awt.image.redrawrate")); > + incRate = (s != null) ? Integer.parseInt(s) : 100; > + } > + > static { > /* ensure that the necessary native libraries are loaded */ > Toolkit.loadLibraries(); > @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer, > if (!GraphicsEnvironment.isHeadless()) { > initIDs(); > } > - > - String s = java.security.AccessController.doPrivileged( > - new GetPropertyAction("awt.image.incrementaldraw")); > - isInc = (s == null || s.equals("true")); > - > - s = java.security.AccessController.doPrivileged( > - new GetPropertyAction("awt.image.redrawrate")); > - incRate = (s != null) ? Integer.parseInt(s) : 100; > + initIncRate(); > } Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From sviswanathan at openjdk.java.net Wed May 19 21:58:37 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 21:58:37 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge master >> - remove whitespace >> - Merge master >> - Small fix >> - cleanup >> - x86 short vector math optimization for Vector API > > Tier 1 to 3 tests pass for the default set of build profiles. Thanks a lot for the review @PaulSandoz @iwanowww @erikj79. Paul and Vladimir, I have implemented your review comments. Please take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From psandoz at openjdk.java.net Wed May 19 22:05:59 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 19 May 2021 22:05:59 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge master >> - remove whitespace >> - Merge master >> - Small fix >> - cleanup >> - x86 short vector math optimization for Vector API > > Tier 1 to 3 tests pass for the default set of build profiles. > Thanks a lot for the review @PaulSandoz @iwanowww @erikj79. > Paul and Vladimir, I have implemented your review comments. Please take a look. `case VECTOR_OP_OR` is still present. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From prr at openjdk.java.net Wed May 19 22:07:36 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 22:07:36 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> Message-ID: On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang wrote: >> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable. >> You can define a static private method to contain this and call it from the static initializer block. >> Much better than applying the annotation to an entire class. >> >> --- a/src/java.desktop/share/classes/java/awt/Component.java >> +++ b/src/java.desktop/share/classes/java/awt/Component.java >> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer, >> */ >> static boolean isInc; >> static int incRate; >> + >> + private static void initIncRate() { >> + String s = java.security.AccessController.doPrivileged( >> + new GetPropertyAction("awt.image.incrementaldraw")); >> + isInc = (s == null || s.equals("true")); >> + >> + s = java.security.AccessController.doPrivileged( >> + new GetPropertyAction("awt.image.redrawrate")); >> + incRate = (s != null) ? Integer.parseInt(s) : 100; >> + } >> + >> static { >> /* ensure that the necessary native libraries are loaded */ >> Toolkit.loadLibraries(); >> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer, >> if (!GraphicsEnvironment.isHeadless()) { >> initIDs(); >> } >> - >> - String s = java.security.AccessController.doPrivileged( >> - new GetPropertyAction("awt.image.incrementaldraw")); >> - isInc = (s == null || s.equals("true")); >> - >> - s = java.security.AccessController.doPrivileged( >> - new GetPropertyAction("awt.image.redrawrate")); >> - incRate = (s != null) ? Integer.parseInt(s) : 100; >> + initIncRate(); >> } > > Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed. I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release. I think it should all be taken care of as part of this proposed change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From sviswanathan at openjdk.java.net Wed May 19 22:16:18 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 22:16:18 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v11] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Commit missing changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/0b4a1c9c..1b0367ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=09-10 Stats: 55 lines in 16 files changed: 2 ins; 42 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Wed May 19 22:16:19 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 22:16:19 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: <5ncMaHLhmfOv3FBOrYSkKmzVXHwQqFks-RPcjuC02Mo=.31de0845-e60a-413a-8984-0ce6e4eac2ed@github.com> On Wed, 19 May 2021 22:02:14 GMT, Paul Sandoz wrote: >> Tier 1 to 3 tests pass for the default set of build profiles. > >> Thanks a lot for the review @PaulSandoz @iwanowww @erikj79. >> Paul and Vladimir, I have implemented your review comments. Please take a look. > > `case VECTOR_OP_OR` is still present. @PaulSandoz Thanks for pointing that out. I had missed git add for some of the files. ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From weijun at openjdk.java.net Wed May 19 22:17:34 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 19 May 2021 22:17:34 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> Message-ID: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> On Wed, 19 May 2021 22:04:57 GMT, Phil Race wrote: >> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed. > > I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release. > I think it should all be taken care of as part of this proposed change. I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From psandoz at openjdk.java.net Wed May 19 22:29:32 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 19 May 2021 22:29:32 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v11] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 22:16:18 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. >> >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. >> These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. >> >> The following changes are made: >> The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. >> The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. >> The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. >> Changes are made to build system to support dependency tracking for assembly files with includes. >> The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. >> The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. >> >> Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). >> >> Looking forward to your review and feedback. >> >> Performance: >> Micro benchmark Base Optimized Unit Gain(Optimized/Base) >> Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 >> Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 >> Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 >> Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 >> Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 >> Double128Vector.COS 49.94 245.89 ops/ms 4.92 >> Double128Vector.COSH 26.91 126.00 ops/ms 4.68 >> Double128Vector.EXP 71.64 379.65 ops/ms 5.30 >> Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 >> Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 >> Double128Vector.LOG 61.95 279.84 ops/ms 4.52 >> Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 >> Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 >> Double128Vector.SIN 49.36 240.79 ops/ms 4.88 >> Double128Vector.SINH 26.59 103.75 ops/ms 3.90 >> Double128Vector.TAN 41.05 152.39 ops/ms 3.71 >> Double128Vector.TANH 45.29 169.53 ops/ms 3.74 >> Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 >> Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 >> Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 >> Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 >> Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 >> Double256Vector.COS 58.26 389.77 ops/ms 6.69 >> Double256Vector.COSH 29.44 151.11 ops/ms 5.13 >> Double256Vector.EXP 86.67 564.68 ops/ms 6.52 >> Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 >> Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 >> Double256Vector.LOG 71.52 394.90 ops/ms 5.52 >> Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 >> Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 >> Double256Vector.SIN 57.06 380.98 ops/ms 6.68 >> Double256Vector.SINH 29.40 117.37 ops/ms 3.99 >> Double256Vector.TAN 44.90 279.90 ops/ms 6.23 >> Double256Vector.TANH 54.08 274.71 ops/ms 5.08 >> Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 >> Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 >> Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 >> Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 >> Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 >> Double512Vector.COS 59.88 837.04 ops/ms 13.98 >> Double512Vector.COSH 30.34 172.76 ops/ms 5.70 >> Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 >> Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 >> Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 >> Double512Vector.LOG 74.84 996.00 ops/ms 13.31 >> Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 >> Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 >> Double512Vector.POW 37.42 384.13 ops/ms 10.26 >> Double512Vector.SIN 59.74 728.45 ops/ms 12.19 >> Double512Vector.SINH 29.47 143.38 ops/ms 4.87 >> Double512Vector.TAN 46.20 587.21 ops/ms 12.71 >> Double512Vector.TANH 57.36 495.42 ops/ms 8.64 >> Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 >> Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 >> Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 >> Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 >> Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 >> Double64Vector.COS 23.42 152.01 ops/ms 6.49 >> Double64Vector.COSH 17.34 113.34 ops/ms 6.54 >> Double64Vector.EXP 27.08 203.53 ops/ms 7.52 >> Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 >> Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 >> Double64Vector.LOG 26.75 142.63 ops/ms 5.33 >> Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 >> Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 >> Double64Vector.SIN 23.28 146.91 ops/ms 6.31 >> Double64Vector.SINH 17.62 88.59 ops/ms 5.03 >> Double64Vector.TAN 21.00 86.43 ops/ms 4.12 >> Double64Vector.TANH 23.75 111.35 ops/ms 4.69 >> Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 >> Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 >> Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 >> Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 >> Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 >> Float128Vector.COS 42.82 803.02 ops/ms 18.75 >> Float128Vector.COSH 31.44 118.34 ops/ms 3.76 >> Float128Vector.EXP 72.43 855.33 ops/ms 11.81 >> Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 >> Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 >> Float128Vector.LOG 52.95 877.94 ops/ms 16.58 >> Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 >> Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 >> Float128Vector.SIN 43.38 745.31 ops/ms 17.18 >> Float128Vector.SINH 31.11 112.91 ops/ms 3.63 >> Float128Vector.TAN 37.25 332.13 ops/ms 8.92 >> Float128Vector.TANH 57.63 453.77 ops/ms 7.87 >> Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 >> Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 >> Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 >> Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 >> Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 >> Float256Vector.COS 43.75 926.69 ops/ms 21.18 >> Float256Vector.COSH 33.52 130.46 ops/ms 3.89 >> Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 >> Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 >> Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 >> Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 >> Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 >> Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 >> Float256Vector.SIN 44.07 911.04 ops/ms 20.67 >> Float256Vector.SINH 33.16 122.50 ops/ms 3.69 >> Float256Vector.TAN 37.85 497.75 ops/ms 13.15 >> Float256Vector.TANH 64.27 537.20 ops/ms 8.36 >> Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 >> Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 >> Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 >> Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 >> Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 >> Float512Vector.COS 40.92 1567.93 ops/ms 38.32 >> Float512Vector.COSH 33.42 138.36 ops/ms 4.14 >> Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 >> Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 >> Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 >> Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 >> Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 >> Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 >> Float512Vector.POW 32.73 1015.85 ops/ms 31.04 >> Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 >> Float512Vector.SINH 33.05 129.39 ops/ms 3.91 >> Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 >> Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 >> Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 >> Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 >> Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 >> Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 >> Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 >> Float64Vector.COS 44.28 394.33 ops/ms 8.91 >> Float64Vector.COSH 28.35 95.27 ops/ms 3.36 >> Float64Vector.EXP 65.80 486.37 ops/ms 7.39 >> Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 >> Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 >> Float64Vector.LOG 51.93 163.25 ops/ms 3.14 >> Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 >> Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 >> Float64Vector.SIN 44.41 382.09 ops/ms 8.60 >> Float64Vector.SINH 28.20 90.68 ops/ms 3.22 >> Float64Vector.TAN 36.29 160.89 ops/ms 4.43 >> Float64Vector.TANH 47.65 214.04 ops/ms 4.49 > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Commit missing changes > @PaulSandoz Thanks for pointing that out. I had missed git add for some of the files. Java changes look good. Please don't integrate when checks pass. I need to work through some JEP details first before we can integrate relevant PRs. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Wed May 19 22:52:09 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 22:52:09 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v12] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge master - Commit missing changes - Implement Vladimir Ivanov and Paul Sandoz review comments - fix 32-bit build - Add comments explaining naming convention - jcheck fixes - Print intrinsic fix - Implement review comments - Add missing Lib.gmk - Merge master - ... and 6 more: https://git.openjdk.java.net/jdk/compare/b961f253...7b959b67 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3638/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=11 Stats: 416021 lines in 119 files changed: 415854 ins; 124 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From sviswanathan at openjdk.java.net Wed May 19 23:01:09 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 19 May 2021 23:01:09 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v13] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: correct ppc.ad ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/7b959b67..4d59af0a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=11-12 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From prr at openjdk.java.net Wed May 19 23:53:35 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 19 May 2021 23:53:35 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang wrote: >> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release. >> I think it should all be taken care of as part of this proposed change. > > I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release. Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork, and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready. I already pasted the patch for Component.java and it took about 60 seconds to do that. Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored. I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Thu May 20 02:09:42 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 20 May 2021 02:09:42 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: On Wed, 19 May 2021 23:50:04 GMT, Phil Race wrote: >> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release. > > Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork, > and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready. > I already pasted the patch for Component.java and it took about 60 seconds to do that. > Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored. > > I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ? I can make it a bug. I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here. And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers. Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Thu May 20 02:12:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 20 May 2021 02:12:33 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang wrote: >> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork, >> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready. >> I already pasted the patch for Component.java and it took about 60 seconds to do that. >> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored. >> >> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ? > > I can make it a bug. > > I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here. > > And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers. > > Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB. By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Thu May 20 04:08:38 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 20 May 2021 04:08:38 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> Message-ID: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang wrote: >> I can make it a bug. >> >> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here. >> >> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers. >> >> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB. > > By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now. That is unfortunate, but nonetheless I think required to be done. We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP. >From my point of view it is a blocker. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Thu May 20 04:25:29 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 20 May 2021 04:25:29 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> Message-ID: On Thu, 20 May 2021 04:05:23 GMT, Phil Race wrote: >> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now. > > That is unfortunate, but nonetheless I think required to be done. > We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP. > From my point of view it is a blocker. The JEP isn't PTT for 17 so there's plenty of time isn't there ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From alanb at openjdk.java.net Thu May 20 07:08:35 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 20 May 2021 07:08:35 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> Message-ID: On Thu, 20 May 2021 04:22:32 GMT, Phil Race wrote: >> That is unfortunate, but nonetheless I think required to be done. >> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP. >> From my point of view it is a blocker. > > The JEP isn't PTT for 17 so there's plenty of time isn't there ? There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From vromero at openjdk.java.net Thu May 20 09:14:33 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 20 May 2021 09:14:33 GMT Subject: Integrated: 8260517: implement Sealed Classes as a standard feature in Java In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 01:08:57 GMT, Vicente Romero wrote: > Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Please also review the related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090) > > Thanks > > note: this PR is related to [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated after it. This pull request has now been integrated. Changeset: 0fa9223f Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/0fa9223f34bc33635079763362f42f0a5c53759b Stats: 444 lines in 54 files changed: 51 ins; 275 del; 118 mod 8260517: implement Sealed Classes as a standard feature in Java Co-authored-by: Harold Seigel Co-authored-by: Vicente Romero Reviewed-by: dholmes, mcimadamore, jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/3526 From prr at openjdk.java.net Thu May 20 16:25:33 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 20 May 2021 16:25:33 GMT Subject: RFR: 8256372: [macos] Unexpected symbol was displayed on JTextField with Monospaced font In-Reply-To: References: Message-ID: <3-T7SVSRZtrKE8hgVILbhHQyCxkZV8FbMMOwQXelPfY=.26cc8ea7-80a5-401a-979a-f5de4fcaf61f@github.com> On Tue, 18 May 2021 19:53:36 GMT, Sergey Bylokhov wrote: >> See the bug report for lots of explanation. >> The short version (not that short) is that Swing adds a new line char to editable TextComponents >> It used to work because harfbuzz asked CoreText which mapped it to an invisible glyph >> Now harfbuzz does its own processing of AAT fonts it is different. >> Harfbuzz looks up the mapping for this but there is none so it gets a missing glyph. >> >> Solution: Since HB now does AAT processing we can dispense with all the special handling of that case >> and core text and just treat AAT fonts like OT fonts. >> This means its gets the same mapping we get when not using Layout. >> >> And the test passes on all platforms .. not just macOS .. > > src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 1: > >> 1: /* > > How we will track these files for the next HB update? Do we need to document it somehow? otherwise, I think it will be added again as a new files. No, they won't. We already pull in only the files we need, not every file, so this is not a precedent. ------------- PR: https://git.openjdk.java.net/jdk/pull/4097 From kcr at openjdk.java.net Thu May 20 18:31:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 20 May 2021 18:31:33 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <58-JOVfSiUl3xFtcjGhwaviPqV-amDLlusvj_yCwmj8=.6d3bbada-4a59-443a-9940-121606b64a71@github.com> On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine. I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected. ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/4073 From serb at openjdk.java.net Thu May 20 19:45:32 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 20 May 2021 19:45:32 GMT Subject: RFR: 8256372: [macos] Unexpected symbol was displayed on JTextField with Monospaced font In-Reply-To: References: Message-ID: On Tue, 18 May 2021 15:55:09 GMT, Phil Race wrote: > See the bug report for lots of explanation. > The short version (not that short) is that Swing adds a new line char to editable TextComponents > It used to work because harfbuzz asked CoreText which mapped it to an invisible glyph > Now harfbuzz does its own processing of AAT fonts it is different. > Harfbuzz looks up the mapping for this but there is none so it gets a missing glyph. > > Solution: Since HB now does AAT processing we can dispense with all the special handling of that case > and core text and just treat AAT fonts like OT fonts. > This means its gets the same mapping we get when not using Layout. > > And the test passes on all platforms .. not just macOS .. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4097 From prr at openjdk.java.net Thu May 20 19:51:47 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 20 May 2021 19:51:47 GMT Subject: Integrated: 8256372: [macos] Unexpected symbol was displayed on JTextField with Monospaced font In-Reply-To: References: Message-ID: On Tue, 18 May 2021 15:55:09 GMT, Phil Race wrote: > See the bug report for lots of explanation. > The short version (not that short) is that Swing adds a new line char to editable TextComponents > It used to work because harfbuzz asked CoreText which mapped it to an invisible glyph > Now harfbuzz does its own processing of AAT fonts it is different. > Harfbuzz looks up the mapping for this but there is none so it gets a missing glyph. > > Solution: Since HB now does AAT processing we can dispense with all the special handling of that case > and core text and just treat AAT fonts like OT fonts. > This means its gets the same mapping we get when not using Layout. > > And the test passes on all platforms .. not just macOS .. This pull request has now been integrated. Changeset: 005d8a7f Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/005d8a7fca8b4d9519d2bde0a7cdbbece1cd3981 Stats: 1425 lines in 9 files changed: 65 ins; 1352 del; 8 mod 8256372: [macos] Unexpected symbol was displayed on JTextField with Monospaced font Reviewed-by: erikj, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/4097 From dfuchs at openjdk.java.net Fri May 21 15:36:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 21 May 2021 15:36:08 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java src/java.base/share/classes/java/lang/SecurityManager.java line 104: > 102: * method will throw an {@code UnsupportedOperationException}). If the > 103: * {@systemProperty java.security.manager} system property is set to the > 104: * special token "{@code allow}", then a security manager will not be set at Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Fri May 21 18:03:01 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 21 May 2021 18:03:01 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> Message-ID: On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman wrote: >> The JEP isn't PTT for 17 so there's plenty of time isn't there ? > > There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover. Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way. It is very straight forward to run the automated tests across all platforms these days. I get the impression that no one is guaranteeing to do this straight after integration. It sounds like it is up for deferral if time runs out. The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound like this JEP is nearly as done as first presented. If there was some expectation that groups responsible for an area would get involved with this issue which I am assured was already known about, then why was it not raised before and made part of the plan ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From prr at openjdk.java.net Fri May 21 20:46:03 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 21 May 2021 20:46:03 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59: > 57: ProcessCommunicator > 58: .executeChildProcess(Consumer.class, new String[0]); > 59: if (!"Hello".equals(processResults.getStdOut())) { Who or what prompted this change ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Fri May 21 20:55:02 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 21 May 2021 20:55:02 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Fri, 21 May 2021 20:43:05 GMT, Phil Race wrote: > I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed > > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > > test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59: > > > 57: ProcessCommunicator > > 58: .executeChildProcess(Consumer.class, new String[0]); > > 59: if (!"Hello".equals(processResults.getStdOut())) { > > Who or what prompted this change ? I replied right in the thread but unfortunately GitHub does not display it at the end of page. This is because the process is now launched with `-Djava.security.manager=allow` (because of another change in https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in stderr. Therefore I switched to stdout. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From alanb at openjdk.java.net Sat May 22 07:00:03 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 22 May 2021 07:00:03 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com> <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com> <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com> Message-ID: On Fri, 21 May 2021 18:00:13 GMT, Phil Race wrote: > Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way. > It is very straight forward to run the automated tests across all platforms these days. > I get the impression that no one is guaranteeing to do this straight after integration. > It sounds like it is up for deferral if time runs out. > > The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound > like this JEP is nearly as done as first presented. > > If there was some expectation that groups responsible for an area would get involved with this > issue which I am assured was already known about, then why was it not raised before and made > part of the plan ? Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR. PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mullan at openjdk.java.net Sun May 23 16:40:59 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Sun, 23 May 2021 16:40:59 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > > src/java.base/share/classes/java/lang/SecurityManager.java line 104: > >> 102: * method will throw an {@code UnsupportedOperationException}). If the >> 103: * {@systemProperty java.security.manager} system property is set to the >> 104: * special token "{@code allow}", then a security manager will not be set at > > Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this. Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, I would just keep the first one. (I think it's ok to have more than one, if they are defined in different APIs). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Mon May 24 13:53:34 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 May 2021 13:53:34 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v4] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: keep only one systemProperty tag ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02-03 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Mon May 24 13:53:37 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 24 May 2021 13:53:37 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v4] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/lang/SecurityManager.java line 104: >> >>> 102: * method will throw an {@code UnsupportedOperationException}). If the >>> 103: * {@systemProperty java.security.manager} system property is set to the >>> 104: * special token "{@code allow}", then a security manager will not be set at >> >> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this. > > Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, so we should remove those too. New commit pushed. There is only one `@systemProperty` tag now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From github.com+28651297+mkartashev at openjdk.java.net Mon May 24 14:15:19 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Mon, 24 May 2021 14:15:19 GMT Subject: RFR: 8265431: Add -fdelete-null-pointer-checks to clang builds Message-ID: <613_hSROow1-21Ut2dEtCeWOkm94P0sKTjoK8TdOblI=.70085637-7cf7-4b1f-bd39-eff529458465@github.com> This commit adds the `-fno-delete-null-pointer-checks` compiler option to clang builds, which is going to become necessary starting from clang version 12.0.0 (see the [bug report](https://bugs.openjdk.java.net/browse/JDK-8265431) for more info). Verified on Linux (with both gcc and clang toolchains) and MacOS (with only the clang toolchain) by - Running configure with `--with-toolchain-type=clang`; the following appears in the configure output: ... checking if BUILD_CC supports "-fno-delete-null-pointer-checks"... yes checking if BUILD_CXX supports "-fno-delete-null-pointer-checks"... yes checking if both BUILD_CC and BUILD_CXX support "-fno-delete-null-pointer-checks"... yes ... * Toolchain: clang (clang/LLVM) * C Compiler: Version 10.0.0 (at /usr/bin/clang) * C++ Compiler: Version 10.0.0 (at /usr/bin/clang++) - Successfully building `make images`. The option is actually passed down to the compiler: $ grep fno-delete-null-pointer-checks .../jdk/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/*cmdline | wc -l 1069 - Running `make run-test-tier1` on Linux. ------------- Commit messages: - 8265431: Add -fdelete-null-pointer-checks to clang builds Changes: https://git.openjdk.java.net/jdk/pull/4166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4166&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265431 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4166/head:pull/4166 PR: https://git.openjdk.java.net/jdk/pull/4166 From godin at openjdk.java.net Tue May 25 09:32:03 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Tue, 25 May 2021 09:32:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 19:01:01 GMT, Jan Lahoda wrote: >> Good work. There's a lot to take in here. I think overall, it holds up well - I like how case labels have been extended to accommodate for patterns. In the front-end, I think there are some questions over the split between Attr and Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis happens in Attr instead of Flow and I left some questions to make sure I understand what's happening. >> >> In the backend it's mostly good work - but overall the structure of the code, both in Lower and in TransPattern is getting very difficult to follow, given there are many different kind of switches each with its own little twist attached to it. It would be nice, I think (maybe in a separate cleanup?) if the code paths serving the different switch kinds could be made more separate, so that, when reading the code we can worry only about one possible code shape. That would make the code easier to document as well. > > @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested changes in recent commits (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 ). > > I've also tried to update the implementation for the latest spec changes here: > https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b > > The spec changes are: total patterns are nullable; pattern matching ("new") statement switches must be complete (as switch expressions). > > Any further feedback is welcome! Hi @lahodaj ? , I tried `javac` built from this PR and for the following `Example.java` class Example { void example(Object o) { switch (o) { case String s && s.length() == 0 -> System.out.println("1st case"); case String s && s.length() == 1 -> // line 6 System.out.println("2nd case"); // line 7 case String s -> // line 8 System.out.println("3rd case"); // line 9 default -> // line 10 System.out.println("default case"); // line 11 } } } execution of javac --enable-preview --release 17 Example.java javap -v -p Example.class produces void example(java.lang.Object); descriptor: (Ljava/lang/Object;)V flags: (0x0000) Code: stack=2, locals=7, args_size=2 0: aload_1 1: dup 2: invokestatic #7 // Method java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object; 5: pop 6: astore_2 7: iconst_0 8: istore_3 9: aload_2 10: iload_3 11: invokedynamic #13, 0 // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I 16: tableswitch { // 0 to 2 0: 44 1: 74 2: 105 default: 122 } 44: aload_2 45: checkcast #17 // class java/lang/String 48: astore 4 50: aload 4 52: invokevirtual #19 // Method java/lang/String.length:()I 55: ifeq 63 58: iconst_1 59: istore_3 60: goto 9 63: getstatic #23 // Field java/lang/System.out:Ljava/io/PrintStream; 66: ldc #29 // String 1st case 68: invokevirtual #31 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 71: goto 133 74: aload_2 75: checkcast #17 // class java/lang/String 78: astore 5 80: aload 5 82: invokevirtual #19 // Method java/lang/String.length:()I 85: iconst_1 86: if_icmpeq 94 89: iconst_2 90: istore_3 91: goto 9 94: getstatic #23 // Field java/lang/System.out:Ljava/io/PrintStream; 97: ldc #37 // String 2nd case 99: invokevirtual #31 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 102: goto 133 105: aload_2 106: checkcast #17 // class java/lang/String 109: astore 6 111: getstatic #23 // Field java/lang/System.out:Ljava/io/PrintStream; 114: ldc #39 // String 3rd case 116: invokevirtual #31 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 119: goto 133 122: getstatic #23 // Field java/lang/System.out:Ljava/io/PrintStream; 125: ldc #41 // String default case 127: invokevirtual #31 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 130: goto 133 133: return LineNumberTable: line 3: 0 line 4: 44 line 5: 63 line 4: 71 line 6: 74 line 7: 94 line 6: 102 line 8: 105 line 9: 111 line 8: 119 line 11: 122 line 8: 130 line 13: 133 I believe `LineNumberTable` entries `line 6: 102`, `line 8: 119` and `line 8: 130` should not be present. Otherwise debugger misleadingly will be showing line `6` after step from line `7`, line `8` after step from line `9` and even more misleadingly line `8` after step from line `11`. This also affects [JaCoCo](https://github.com/jacoco/jacoco) Java Code Coverage tool (I'm one of its developers), which relies on LineNumberTable to provide code coverage highlighting and these entries cause misleading highlighting - partial coverage of line `8` when default case was not executed. Should I create separate ticket about this in https://bugs.openjdk.java.net/ or this comment here is enough? ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From forax at univ-mlv.fr Tue May 25 11:42:52 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 25 May 2021 13:42:52 +0200 (CEST) Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: <2070914630.587750.1621942972319.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Evgeny Mandrikov" > ?: "build-dev" , "compiler-dev" , "core-libs-dev" > , "javadoc-dev" > Envoy?: Mardi 25 Mai 2021 11:32:03 > Objet: Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] > On Mon, 17 May 2021 19:01:01 GMT, Jan Lahoda wrote: > >>> Good work. There's a lot to take in here. I think overall, it holds up well - I >>> like how case labels have been extended to accommodate for patterns. In the >>> front-end, I think there are some questions over the split between Attr and >>> Flow - maybe it is unavoidable, but I'm not sure why some control-flow analysis >>> happens in Attr instead of Flow and I left some questions to make sure I >>> understand what's happening. >>> >>> In the backend it's mostly good work - but overall the structure of the code, >>> both in Lower and in TransPattern is getting very difficult to follow, given >>> there are many different kind of switches each with its own little twist >>> attached to it. It would be nice, I think (maybe in a separate cleanup?) if the >>> code paths serving the different switch kinds could be made more separate, so >>> that, when reading the code we can worry only about one possible code shape. >>> That would make the code easier to document as well. >> >> @mcimadamore, @forax, thanks a lot for comments! I tried to apply the requested >> changes in recent commits >> (https://github.com/openjdk/jdk/pull/3863/commits/3fc2502a33cec20f39fe571eb25538ee3b459a9b >> https://github.com/openjdk/jdk/pull/3863/commits/aeddb85e65bf77ed62dc7fa1ad00c29646d02c99 >> ). >> >> I've also tried to update the implementation for the latest spec changes here: >> https://github.com/openjdk/jdk/pull/3863/commits/54ba974e1aac00bbde1c3bd2627f01caaaeda09b >> >> The spec changes are: total patterns are nullable; pattern matching ("new") >> statement switches must be complete (as switch expressions). >> >> Any further feedback is welcome! > > Hi @lahodaj ? , > > I tried `javac` built from this PR and for the following `Example.java` > > > class Example { > void example(Object o) { > switch (o) { > case String s && s.length() == 0 -> > System.out.println("1st case"); > case String s && s.length() == 1 -> // line 6 > System.out.println("2nd case"); // line 7 > case String s -> // line 8 > System.out.println("3rd case"); // line 9 > default -> // line 10 > System.out.println("default case"); // line 11 > } > } > } > > > execution of > > > javac --enable-preview --release 17 Example.java > javap -v -p Example.class > > > produces > > > void example(java.lang.Object); > descriptor: (Ljava/lang/Object;)V > flags: (0x0000) > Code: > stack=2, locals=7, args_size=2 > 0: aload_1 > 1: dup > 2: invokestatic #7 // Method > java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object; > 5: pop > 6: astore_2 > 7: iconst_0 > 8: istore_3 > 9: aload_2 > 10: iload_3 > 11: invokedynamic #13, 0 // InvokeDynamic > #0:typeSwitch:(Ljava/lang/Object;I)I > 16: tableswitch { // 0 to 2 > 0: 44 > 1: 74 > 2: 105 > default: 122 > } > 44: aload_2 > 45: checkcast #17 // class java/lang/String > 48: astore 4 > 50: aload 4 > 52: invokevirtual #19 // Method java/lang/String.length:()I > 55: ifeq 63 > 58: iconst_1 > 59: istore_3 > 60: goto 9 > 63: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 66: ldc #29 // String 1st case > 68: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 71: goto 133 > 74: aload_2 > 75: checkcast #17 // class java/lang/String > 78: astore 5 > 80: aload 5 > 82: invokevirtual #19 // Method java/lang/String.length:()I > 85: iconst_1 > 86: if_icmpeq 94 > 89: iconst_2 > 90: istore_3 > 91: goto 9 > 94: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 97: ldc #37 // String 2nd case > 99: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 102: goto 133 > 105: aload_2 > 106: checkcast #17 // class java/lang/String > 109: astore 6 > 111: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 114: ldc #39 // String 3rd case > 116: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 119: goto 133 > 122: getstatic #23 // Field > java/lang/System.out:Ljava/io/PrintStream; > 125: ldc #41 // String default case > 127: invokevirtual #31 // Method > java/io/PrintStream.println:(Ljava/lang/String;)V > 130: goto 133 > 133: return > LineNumberTable: > line 3: 0 > line 4: 44 > line 5: 63 > line 4: 71 > line 6: 74 > line 7: 94 > line 6: 102 > line 8: 105 > line 9: 111 > line 8: 119 > line 11: 122 > line 8: 130 > line 13: 133 > > > I believe `LineNumberTable` entries `line 6: 102`, `line 8: 119` and `line 8: > 130` should not be present. > Otherwise debugger misleadingly will be showing > line `6` after step from line `7`, > line `8` after step from line `9` > and even more misleadingly line `8` after step from line `11`. > > This also affects [JaCoCo](https://github.com/jacoco/jacoco) Java Code Coverage > tool (I'm one of its developers), which relies on LineNumberTable to provide > code coverage highlighting and these entries cause misleading highlighting - > partial coverage of line `8` when default case was not executed. > > Should I create separate ticket about this in https://bugs.openjdk.java.net/ or > this comment here is enough? Also why invokedynamic take a constant int as second argument ? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3863 R?mi From jlahoda at openjdk.java.net Tue May 25 12:22:56 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 25 May 2021 12:22:56 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 08:00:12 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing various error-related bugs. Thanks Evgeny, I'll take a look. @forax, do you mean why there is "0" in: 11: invokedynamic #13, 0 ? The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From forax at openjdk.java.net Tue May 25 14:16:59 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 25 May 2021 14:16:59 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 12:20:02 GMT, Jan Lahoda wrote: > Thanks Evgeny, I'll take a look. > > @forax, do you mean why there is "0" in: > 11: invokedynamic #13, 0 > ? Not this one, the one on the stack. 7: iconst_0 <---- this zero 8: istore_3 9: aload_2 10: iload_3 11: invokedynamic #13, 0 // InvokeDynamic #0:typeSwitch:(Ljava/lang/Object;I)I Why the descriptor is (Ljava/lang/Object;I)I instead of (Ljava/lang/Object;)I, what is the semantics associated to that integer ? > The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK. I know that a little to well, i'm one of the guys behind the design of indy :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Tue May 25 14:25:03 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 25 May 2021 14:25:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:13:55 GMT, R?mi Forax wrote: > > Thanks Evgeny, I'll take a look. > > @forax, do you mean why there is "0" in: > > 11: invokedynamic #13, 0 > > ? > > Not this one, the one on the stack. > > 7: iconst_0 <---- this zero > 8: istore_3 > 9: aload_2 > 10: iload_3 > 11: invokedynamic #13, 0 // InvokeDynamic > #0:typeSwitch:(Ljava/lang/Object;I)I > > Why the descriptor is (Ljava/lang/Object;I)I instead of (Ljava/lang/Object;)I, > what is the semantics associated to that integer ? The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here: class Example { void example(Object o) { switch (o) { case String s && s.length() == 0 -> System.out.println("1st case"); case String s && s.length() == 1 -> // line 6 System.out.println("2nd case"); // line 7 case String s -> // line 8 System.out.println("3rd case"); // line 9 default -> // line 10 System.out.println("default case"); // line 11 } } } If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac. > > > The "0" is an artifact of how invokedynamic is represented in the classfile (invokedynamic, 2 bytes of constant pool reference, byte 0, byte 0) - javap shows the value of the first zero byte. That is probably not needed anymore, but there is nothing special in this patch, I think - all invokedynamic calls look like this, AFAIK. > > I know that a little to well, i'm one of the guys behind the design of indy :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From godin at openjdk.java.net Tue May 25 14:25:02 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Tue, 25 May 2021 14:25:02 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:13:55 GMT, R?mi Forax wrote: > 7: iconst_0 <---- this zero @forax as far as I understood this will be a value of parameter `startIndex` in `java.lang.runtime. SwitchBootstraps.doSwitch` ? Please correct me @lahodaj if I'm wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From forax at openjdk.java.net Tue May 25 16:03:56 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 25 May 2021 16:03:56 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:22:57 GMT, Jan Lahoda wrote: > The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here: > > ``` > class Example { > void example(Object o) { > switch (o) { > case String s && s.length() == 0 -> > System.out.println("1st case"); > case String s && s.length() == 1 -> // line 6 > System.out.println("2nd case"); // line 7 > case String s -> // line 8 > System.out.println("3rd case"); // line 9 > default -> // line 10 > System.out.println("default case"); // line 11 > } > } > } > ``` > > If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac. The problem with this design is that calling example("foo") forces the VM will do 6 checkcast String on "foo", and it doesn't work with sub-patterns. Desugaring the guards as static method like with lambdas seems more promising, indy can be called with the pairs [String, MethodHandle(s -> s.length() == 0)], [String, MethodHandle(s -> s.length() == 0)] and [_,_] (with the guards passed as a constant method handles again like lambdas are desugared). It means that the indy needs to capture all local variables that are used in the guards, instead of passing an int. I believe that a translation using constant method handles for guards is far more efficient than using an int and a backward branch but it has a higher cost in term of runtime data structures. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Tue May 25 16:17:59 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 25 May 2021 16:17:59 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: References: Message-ID: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com> On Tue, 25 May 2021 16:00:43 GMT, R?mi Forax wrote: > > The reason for this integer (which is not a constant in the case of this switch) is to restart the matching in case guards fail to "match". Considering the example here: > > ``` > > class Example { > > void example(Object o) { > > switch (o) { > > case String s && s.length() == 0 -> > > System.out.println("1st case"); > > case String s && s.length() == 1 -> // line 6 > > System.out.println("2nd case"); // line 7 > > case String s -> // line 8 > > System.out.println("3rd case"); // line 9 > > default -> // line 10 > > System.out.println("default case"); // line 11 > > } > > } > > } > > ``` > > > > > > > > > > > > > > > > > > > > > > > > If `o` is `String`, then the first call to indy will be `indy[...](o, 0)`, returning `0`. Then the guard will be evaluated `s.length() == 0`. If the length is not zero, the local variable 3 will be reassigned to `1`(bytecode index 58, 59) and the whole switch is restarted - just this time, the matching in the indy will start at index `1`, not `0`, i.e. `indy[...](o, 1)`. And so on. I believe there is a text explaining the meaning of the parameter in the javadoc of the bootstrap, and in TransPatterns in javac. > > The problem with this design is that calling example("foo") forces the VM will do 6 checkcast String on "foo", and it doesn't work with sub-patterns. Desugaring the guards as static method like with lambdas seems more promising, indy can be called with the pairs [String, MethodHandle(s -> s.length() == 0)], [String, MethodHandle(s -> s.length() == 0)] and [_,_] (with the guards passed as a constant method handles again like lambdas are desugared). > It means that the indy needs to capture all local variables that are used in the guards, instead of passing an int. > > I believe that a translation using constant method handles for guards is far more efficient than using an int and a backward branch but it has a higher cost in term of runtime data structures. I'd like to note this is a preview feature - we can change the desugaring. At the same time, I don't think this does not work with sub-patterns (those can be easily desugared to guards, I think). Regarding efficiency, it may be a balance between classfile overhead (which will be higher if we need to desugar every guard to a separate method), and the possibility to tweak the matching at runtime. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From sviswanathan at openjdk.java.net Tue May 25 20:19:04 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 25 May 2021 20:19:04 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v14] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Javadoc changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/4d59af0a..6cd50248 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=12-13 Stats: 58 lines in 1 file changed: 38 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From vromero at openjdk.java.net Tue May 25 21:43:58 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 25 May 2021 21:43:58 GMT Subject: RFR: 8267312: Resolve should use generated diagnostic factories In-Reply-To: References: Message-ID: On Tue, 18 May 2021 11:07:18 GMT, Maurizio Cimadamore wrote: > This patch allows Resolve to use more static diagnostic factories. Resolution errors support generation of diagnostics. This generation is very flexible and allows creating either a toplevel (error or warning) diagnostic, or a nested (fragment) diagostic. To support this, many resolution diagnostics in javac define some "overloads" in compiler.properties - e.g. > > > # 0: message segment > compiler.err.prob.found.req=... > # 0: message segment > compiler.misc.prob.found.req=... > # 0: message segment, 1: type, 2: type > compiler.warn.prob.found.req=... > > > To support switching from one diagnostic kind to another, this patch adds a new method on `DiagnosticInfo`, namely `toType(DiagnosticType)`. The default implementation of this method will simply check that the type is identical to that of the current diagnostic info, and throw otherwise. > > This patch modifies the build-time step to construct diagnostic factories, so that, whenever a diagnostic overload is detected, the `toType` method is overridden, and the right constants/factories are returned/called depending on the requested diagnostic type. For instance, the factory for the `prob.found.req` key will look as follows in the generated code: > > > /** > * compiler.err.prob.found.req=\ > * incompatible types: {0} > */ > public static Error ProbFoundReq(Fragment arg0) { > return new Error("compiler", "prob.found.req", arg0) { > public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) { > return switch (kind) { > case ERROR -> this; > case WARNING -> throw new AssertionError("Unsupported kind: " + kind); > case FRAGMENT -> Fragments.ProbFoundReq(arg0); > case NOTE -> throw new AssertionError("Unsupported kind: " + kind); > }; > } > }; > } > > > As you can see, the build time process correctly detects all diagnostic overloads and generate some code to convert one diagnostic info to another. Note that in this case, only two overloads are detected (`err` and `misc`), given that `warn` has a different type comment so not, technically speaking, an overload. > > With this support it is relatively easy to go back to Resolve and update most of the resolution errors to use the generated factories. > > The only case I have not dealt with is the "cannot.resolve" diagnostic, which has many variants: `{ var, method, generic method } x { location, no location }`. To use the factories effectively here a change in the way the diagnostic is structured is required, but doing so, while trivial, will cause many change in the golden test files, so I held off these changes for now, and will come back later to this. Some general comments about the generated code. I wonder if it would make sense to change the implementation of the toType() method which will fold common cases in the switch expression into a default case or generate a case label like: `case Type1, Type2 -> sameAction`. Another thing I found is that the generated code has "mirror" code I mean we have for example: public static final Fragment UncheckedCastToType = new Fragment("compiler", "unchecked.cast.to.type") { public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) { return switch (kind) { case ERROR -> throw new AssertionError("Unsupported kind: " + kind); case WARNING -> Warnings.UncheckedCastToType; case FRAGMENT -> this; case NOTE -> throw new AssertionError("Unsupported kind: " + kind); }; } }; and public static final Warning UncheckedCastToType = new Warning("compiler", "unchecked.cast.to.type") { public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) { return switch (kind) { case ERROR -> throw new AssertionError("Unsupported kind: " + kind); case WARNING -> this; case FRAGMENT -> Fragments.UncheckedCastToType; case NOTE -> throw new AssertionError("Unsupported kind: " + kind); }; } }; I wonder if what we really want to model is one factory that can fold both implementations into one. I know this is generated code which should be ready to use, but just thinking aloud, not sure if there are some abstractions that could be useful from the client code perspective. I wonder if we could build on method DiagnosticInfo::of to define one stop factories. But I guess that you already considered this option. ------------- PR: https://git.openjdk.java.net/jdk/pull/4089 From sviswanathan at openjdk.java.net Tue May 25 22:02:39 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 25 May 2021 22:02:39 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v15] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: correct javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/6cd50248..e5208a18 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=13-14 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From smarks at openjdk.java.net Tue May 25 22:26:43 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 25 May 2021 22:26:43 GMT Subject: RFR: 8267123: Remove RMI Activation Message-ID: This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). This is a fairly straightforward removal of this component. - Activation implementation classes removed - Activation tests removed - adjustments to various comments to remove references to Activation - adjustments to some code to remove special-case support for Activation from core RMI - adjustments to several tests to remove testing and support for, and mentions of Activation - remove `rmid` tool (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) ------------- Commit messages: - Merge branch 'master' into JDK-8267123-Remove-RMI-Activation - Merge branch 'master' into remove-rmi-activation - Clean up some old comments. - Small fixups. - First cut at removal of RMI Activation. Changes: https://git.openjdk.java.net/jdk/pull/4194/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4194&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267123 Stats: 21982 lines in 243 files changed: 0 ins; 21930 del; 52 mod Patch: https://git.openjdk.java.net/jdk/pull/4194.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4194/head:pull/4194 PR: https://git.openjdk.java.net/jdk/pull/4194 From erikj at openjdk.java.net Tue May 25 22:41:16 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 25 May 2021 22:41:16 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4194 From alanb at openjdk.java.net Wed May 26 06:24:22 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 26 May 2021 06:24:22 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) One other test that might need an update is test/jdk/sun/rmi/log/ReliableLog/LogAlignmentTest.java, it might be just the summary. ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From mcimadamore at openjdk.java.net Wed May 26 14:12:15 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 26 May 2021 14:12:15 GMT Subject: RFR: 8267312: Resolve should use generated diagnostic factories In-Reply-To: References: Message-ID: On Tue, 25 May 2021 19:27:35 GMT, Vicente Romero wrote: > Some general comments about the generated code. I wonder if it would make sense to change the implementation of the toType() method which will fold common cases in the switch expression into a default case or generate a case label like: `case Type1, Type2 -> sameAction`. I'll think about this - my first reaction is that the current strategy makes templating easier, but perhaps there's another way - e.g. by having a template for a single CASE statement, which can be parameterized on a number of labels. > I wonder if what we really want to model is one factory that can fold both implementations into one. I know this is generated code which should be ready to use, but just thinking aloud, not sure if there are some abstractions that could be useful from the client code perspective. I wonder if we could build on method DiagnosticInfo::of to define one stop factories. But I guess that you already considered this option. I guess what you are suggesting is that, instead of having a method for converting a diagnostic info to a different one (like we do now) we should have a method to create a diagnostic info with the right kind from the start. This is definitively an option - one of the issues is that the current generated file is divided by kinds (e.g. CompilerProperties has nested classes like Errors, Warnings, Notes) - so if we added such factories, they'd have to live at the top level (e.g. CompilerProperties). If that's acceptable I can do that. To be clear, the proposed structure will end up like this: class CompilerProperties { static class Errors { static DiagnosticInfo ProbFoundReq(...) = ... // like before this patch ... } static class Fragments { static DiagnosticInfo ProbFoundReq(...) = ... // like before this patch ... } // shared factories static DiagnosticInfo ProbFoundReq(DiagnosticType type, args...) { return switch (type) { case ERROR -> Errors.ProbFoundReq(args); case MISC -> Fragments.ProbFoundReq(args); default -> throw new AssertionError(); }; } } This would solve the problem you mention, and also avoid a redundant allocation in Resolve.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/4089 From jlahoda at openjdk.java.net Wed May 26 17:52:36 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 26 May 2021 17:52:36 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. - Correcting LineNumberTable for rule switches. - Merging master into JDK-8262891 - Fixing various error-related bugs. - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. - Reflecting recent spec changes. - Reflecting review comments. - Reflecting review comments on SwitchBootstraps. - Trailing whitespaces. - Cleanup, reflecting review comments. - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=04 Stats: 4551 lines in 77 files changed: 4235 ins; 119 del; 197 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From rriggs at openjdk.java.net Wed May 26 18:35:21 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 26 May 2021 18:35:21 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4194 From jlahoda at openjdk.java.net Wed May 26 19:42:12 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 26 May 2021 19:42:12 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 In: https://github.com/openjdk/jdk/pull/3863/commits/7d1abc141ecfecaf0798a2bad899705c116154e7 I've updated the code to produce better/more useful LineNumberTable for rule switches. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From smarks at openjdk.java.net Wed May 26 19:49:04 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 26 May 2021 19:49:04 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: <6dMALeSEys26_TFkj3m4WSgOehMYVZuZzUHRQf9kp3I=.b3b00dab-9265-4522-88e6-fc0cb9593a3f@github.com> On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) AlanBateman wrote: > test/jdk/sun/rmi/log/ReliableLog/LogAlignmentTest.java Oh yes, this test mentions `rmid`, but it is basically a direct test of the `ReliableLog` stuff and it doesn't actually use or depend on Activation or `rmid`. The test still runs and passes. I'll do a followup pass to see if anything in the system uses anything in the `sun.rmi.log` package. Maybe the only user was Activation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From forax at openjdk.java.net Wed May 26 20:24:06 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 26 May 2021 20:24:06 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v4] In-Reply-To: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com> References: <6SO8Ij_klMovO-wcF_I8rjji8VVd8-BSergVJ_4K7ZQ=.f04b7334-b9ee-46c5-9c0e-93d79a015004@github.com> Message-ID: On Tue, 25 May 2021 16:14:56 GMT, Jan Lahoda wrote: > I'd like to note this is a preview feature - we can change the desugaring. At the same time, I don't think this does not work with sub-patterns (those can be easily desugared to guards, I think). Yes, but in that case the classcheck du to a sub-pattern matching will be either an instanceof or some other invokedynamic. Having several indy will bloat the code and if we use instanceof, why not using instanceof all along the way. > Regarding efficiency, it may be a balance between classfile overhead (which will be higher if we need to desugar every guard to a separate method), and the possibility to tweak the matching at runtime. I fear more the 2 bytes length bytecode limit of a method than the constant pool length limit mostly because people are already using a bunch of lambdas to simulate pattern matching. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From alanb at openjdk.java.net Thu May 27 05:53:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 27 May 2021 05:53:14 GMT Subject: RFR: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From mcimadamore at openjdk.java.net Thu May 27 10:45:11 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 27 May 2021 10:45:11 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 Compiler changes look good src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1657: > 1655: > 1656: try { > 1657: boolean enumSwitch = (seltype.tsym.flags() & Flags.ENUM) != 0; This is getting convoluted enough that an enum on the AST (e.g. SwitchKind) might be helpful to save some of these classification properties - which I imagine we have to redo at some point later (e.g. in Lower/TransPattern). I'm ok with fixing in a followup issue. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3863 From hannesw at openjdk.java.net Thu May 27 11:02:16 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 27 May 2021 11:02:16 GMT Subject: RFR: JDK-8263468: New page for "recent" new API Message-ID: This adds a new kind of summary list for new API added in specific releases, and adds information to the deprecated API list about elements that were deprecated in the given releases. The changes to the code are relatively minor thanks to the existing infrastructure for summary list pages, which was extended by adding the `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in order to generate tabbed tables. One important area that needs to be reviewed is the addition of resources in `standard.properties`. A relatively big share of discussion and effort went into shaping the UI messages. The build system change adds options to generate API changes for all releases after JDK 11, with "New API since JDK 11" as page title for the new API page. ------------- Commit messages: - JDK-8263468: make constant static - JDK-8263468: Remove unused DocPaths methods - JDK-8263468: Cleanup - JDK-8263468: Add tests - JDK-8263468: Update to new Table methods - Merge branch 'master' into JDK-8263468 - JDK-8263468: Fix tests - JDK-8263468: Update to latest CSR - JDK-8263468: Tweak help message wording - JDK-8263468: Rename -since to --since, add --since-name option - ... and 4 more: https://git.openjdk.java.net/jdk/compare/9eaa4afc...e81532b2 Changes: https://git.openjdk.java.net/jdk/pull/4209/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263468 Stats: 1921 lines in 38 files changed: 1842 ins; 38 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/4209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4209/head:pull/4209 PR: https://git.openjdk.java.net/jdk/pull/4209 From erikj at openjdk.java.net Thu May 27 12:55:06 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 May 2021 12:55:06 GMT Subject: RFR: JDK-8263468: New page for "recent" new API In-Reply-To: References: Message-ID: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> On Wed, 26 May 2021 16:02:29 GMT, Hannes Walln?fer wrote: > This adds a new kind of summary list for new API added in specific releases, and adds information to the deprecated API list about elements that were deprecated in the given releases. > > The changes to the code are relatively minor thanks to the existing infrastructure for summary list pages, which was extended by adding the `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in order to generate tabbed tables. > > One important area that needs to be reviewed is the addition of resources in `standard.properties`. A relatively big share of discussion and effort went into shaping the UI messages. > > The build system change adds options to generate API changes for all releases after JDK 11, with "New API since JDK 11" as page title for the new API page. I uploaded the generated documentation here: > > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html make/Docs.gmk line 336: > 334: > 335: # Add summary pages for new/deprecated APIs in recent releases > 336: $1_OPTIONS += --since 12,13,14,15,16,17 --since-label "New API since JDK 11" How do you expect this to change as the JDK version is bumped? If there is an expected pattern, then maybe we should try to generate the list instead, so we don't need to manually update twice a year. ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From hannesw at openjdk.java.net Thu May 27 13:08:08 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 27 May 2021 13:08:08 GMT Subject: RFR: JDK-8263468: New page for "recent" new API In-Reply-To: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> References: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> Message-ID: On Thu, 27 May 2021 12:52:34 GMT, Erik Joelsson wrote: >> This adds a new kind of summary list for new API added in specific releases, and adds information to the deprecated API list about elements that were deprecated in the given releases. >> >> The changes to the code are relatively minor thanks to the existing infrastructure for summary list pages, which was extended by adding the `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in order to generate tabbed tables. >> >> One important area that needs to be reviewed is the addition of resources in `standard.properties`. A relatively big share of discussion and effort went into shaping the UI messages. >> >> The build system change adds options to generate API changes for all releases after JDK 11, with "New API since JDK 11" as page title for the new API page. I uploaded the generated documentation here: >> >> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html >> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html > > make/Docs.gmk line 336: > >> 334: >> 335: # Add summary pages for new/deprecated APIs in recent releases >> 336: $1_OPTIONS += --since 12,13,14,15,16,17 --since-label "New API since JDK 11" > > How do you expect this to change as the JDK version is bumped? If there is an expected pattern, then maybe we should try to generate the list instead, so we don't need to manually update twice a year. I don't have a solution for this problem. AFAIK there are a few things that have to be "bumped" manually between releases, and this would be yet another. Obviously not a great solution. ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From erikj at openjdk.java.net Thu May 27 13:31:07 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 May 2021 13:31:07 GMT Subject: RFR: JDK-8263468: New page for "recent" new API In-Reply-To: References: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> Message-ID: On Thu, 27 May 2021 13:05:27 GMT, Hannes Walln?fer wrote: >> make/Docs.gmk line 336: >> >>> 334: >>> 335: # Add summary pages for new/deprecated APIs in recent releases >>> 336: $1_OPTIONS += --since 12,13,14,15,16,17 --since-label "New API since JDK 11" >> >> How do you expect this to change as the JDK version is bumped? If there is an expected pattern, then maybe we should try to generate the list instead, so we don't need to manually update twice a year. > > I don't have a solution for this problem. AFAIK there are a few things that have to be "bumped" manually between releases, and this would be yet another. Obviously not a great solution. Yes, there are a few things, but in the build itself, we are down to a single config file today, so I would really appreciate if this could be figured out. I can provide the implementation for generating this, but I need to understand what the expected pattern is. From what I can see, it looks like $(sequence N, M) where N is the last LTS+1 and M is current JDK version. Then the string has "JDK N" in it. M is already well defined, so the only new input here is N, which we could move to the version numbers config file (make/conf/version-numbers.conf). Something like DEFAULT_VERSION_DOCS_API_SINCE=11. There is some additional boilerplate needed, and the sequence macro of course, but does this sound reasonable to you? ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From erikj at openjdk.java.net Thu May 27 13:36:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 May 2021 13:36:03 GMT Subject: RFR: JDK-8263468: New page for "recent" new API In-Reply-To: References: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> Message-ID: On Thu, 27 May 2021 13:28:33 GMT, Erik Joelsson wrote: >> I don't have a solution for this problem. AFAIK there are a few things that have to be "bumped" manually between releases, and this would be yet another. Obviously not a great solution. > > Yes, there are a few things, but in the build itself, we are down to a single config file today, so I would really appreciate if this could be figured out. I can provide the implementation for generating this, but I need to understand what the expected pattern is. From what I can see, it looks like $(sequence N, M) where N is the last LTS+1 and M is current JDK version. Then the string has "JDK N" in it. M is already well defined, so the only new input here is N, which we could move to the version numbers config file (make/conf/version-numbers.conf). Something like DEFAULT_VERSION_DOCS_API_SINCE=11. There is some additional boilerplate needed, and the sequence macro of course, but does this sound reasonable to you? We actually have a sequence macro already, so generating the list can be done like this: $(call CommaList,$(call sequence 12, 17)) Or if what you have is 11 and 17: $(call CommaList, $(filter-out 11, $(call sequence 11, 17))) ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From github.com+9004656+yaaz at openjdk.java.net Thu May 27 15:06:19 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Thu, 27 May 2021 15:06:19 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL Message-ID: 8267706: bin/idea.sh tries to use cygpath on WSL ------------- Commit messages: - 8267706: Added shell run configurations instead of Ant for IDEA project - 8267706: Improved IDEA project setup - 8267706: Fix bin/idea.sh cygpath usage on WSL Changes: https://git.openjdk.java.net/jdk/pull/4190/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4190&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267706 Stats: 668 lines in 14 files changed: 67 ins; 498 del; 103 mod Patch: https://git.openjdk.java.net/jdk/pull/4190.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4190/head:pull/4190 PR: https://git.openjdk.java.net/jdk/pull/4190 From smarks at openjdk.java.net Thu May 27 15:23:10 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 27 May 2021 15:23:10 GMT Subject: Integrated: 8267123: Remove RMI Activation In-Reply-To: References: Message-ID: On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks wrote: > This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407). > > This is a fairly straightforward removal of this component. > - Activation implementation classes removed > - Activation tests removed > - adjustments to various comments to remove references to Activation > - adjustments to some code to remove special-case support for Activation from core RMI > - adjustments to several tests to remove testing and support for, and mentions of Activation > - remove `rmid` tool > > (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.) This pull request has now been integrated. Changeset: 7c85f351 Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/7c85f3510cb84881ff232548fbcc933ef4b34972 Stats: 21982 lines in 243 files changed: 0 ins; 21930 del; 52 mod 8267123: Remove RMI Activation Reviewed-by: erikj, rriggs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/4194 From vromero at openjdk.java.net Thu May 27 15:59:03 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 27 May 2021 15:59:03 GMT Subject: RFR: 8267312: Resolve should use generated diagnostic factories In-Reply-To: References: Message-ID: On Wed, 26 May 2021 14:09:39 GMT, Maurizio Cimadamore wrote: > > Some general comments about the generated code. I wonder if it would make sense to change the implementation of the toType() method which will fold common cases in the switch expression into a default case or generate a case label like: `case Type1, Type2 -> sameAction`. > > I'll think about this - my first reaction is that the current strategy makes templating easier, but perhaps there's another way - e.g. by having a template for a single CASE statement, which can be parameterized on a number of labels. if templating is easier the way it is in your current proposal, I would keep it that way > > > I wonder if what we really want to model is one factory that can fold both implementations into one. I know this is generated code which should be ready to use, but just thinking aloud, not sure if there are some abstractions that could be useful from the client code perspective. I wonder if we could build on method DiagnosticInfo::of to define one stop factories. But I guess that you already considered this option. > > I guess what you are suggesting is that, instead of having a method for converting a diagnostic info to a different one (like we do now) we should have a method to create a diagnostic info with the right kind from the start. > > This is definitively an option - one of the issues is that the current generated file is divided by kinds (e.g. CompilerProperties has nested classes like Errors, Warnings, Notes) - so if we added such factories, they'd have to live at the top level (e.g. CompilerProperties). If that's acceptable I can do that. To be clear, the proposed structure will end up like this: > > ``` > class CompilerProperties { > static class Errors { > static DiagnosticInfo ProbFoundReq(...) = ... // like before this patch > ... > } > static class Fragments { > static DiagnosticInfo ProbFoundReq(...) = ... // like before this patch > ... > } > > // shared factories > > static DiagnosticInfo ProbFoundReq(DiagnosticType type, args...) { > return switch (type) { > case ERROR -> Errors.ProbFoundReq(args); > case MISC -> Fragments.ProbFoundReq(args); > default -> throw new AssertionError(); > }; > } > } > ``` > > This would solve the problem you mention, and also avoid a redundant allocation in Resolve.java. right I like the shared factories proposal, I think the generated code will be simpler ------------- PR: https://git.openjdk.java.net/jdk/pull/4089 From erikj at openjdk.java.net Thu May 27 16:55:08 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 May 2021 16:55:08 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:37:30 GMT, Nikita Gubarkov wrote: > 8267706: bin/idea.sh tries to use cygpath on WSL I think this looks ok, though I'm not very familiar with the details of this code. I also very rarely use the idea projects. It would be good if some frequent users could take this for a spin. make/ide/idea/jdk/idea.gmk line 50: > 48: idea: > 49: $(ECHO) "SUPPORT=$(SUPPORT_OUTPUTDIR)" > $(OUT) > 50: $(ECHO) "MODULES=\"$(foreach mod, $(SEL_MODULES), module='$(mod)' moduleSrcDirs='$(call FindModuleSrcDirs,$(mod))' moduleDependencies='$(call FindTransitiveDepsForModule,$(mod))' #)\"" >> $(OUT) If you can find a way to break this line, it would be appreciated. We try to keep line length "reasonable" within the build files. (Reasonable meaning, not strict 80, but with future 3-way merges on a normal screen in mind) ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4190 From prr at openjdk.java.net Thu May 27 17:15:06 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 27 May 2021 17:15:06 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v4] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > keep only one systemProperty tag Marked as reviewed by prr (Reviewer). I'm OK with this now given that the refactoring is already underway at https://github.com/openjdk/jdk/pull/4138 ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From github.com+9004656+yaaz at openjdk.java.net Thu May 27 17:45:40 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Thu, 27 May 2021 17:45:40 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: References: Message-ID: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> > 8267706: bin/idea.sh tries to use cygpath on WSL Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: 8267706: Break long line in make/ide/idea/jdk/idea.gmk ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4190/files - new: https://git.openjdk.java.net/jdk/pull/4190/files/e1617757..f8d6c405 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4190&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4190&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4190.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4190/head:pull/4190 PR: https://git.openjdk.java.net/jdk/pull/4190 From godin at openjdk.java.net Thu May 27 18:06:20 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Thu, 27 May 2021 18:06:20 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 > I've updated the code to produce better/more useful LineNumberTable for rule switches. @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries ? ---- However I also noticed that for class Example { void example(String s) { switch (s) { case "a": System.out.println("a"); } } } there is difference in frames before and after this PR javap -v -p Example.class diff is line 3: 0 line 5: 60 line 7: 68 - StackMapTable: number_of_entries = 4 + StackMapTable: number_of_entries = 5 frame_type = 253 /* append */ - offset_delta = 28 + offset_delta = 4 locals = [ class java/lang/String, int ] + frame_type = 23 /* same */ frame_type = 10 /* same */ frame_type = 20 /* same */ frame_type = 249 /* chop */ and java -cp asm-util-9.1.jar:asm-9.1.jar org.objectweb.asm.util.Textifier Example.class diff is + L1 + FRAME APPEND [java/lang/String I] ALOAD 2 INVOKEVIRTUAL java/lang/String.hashCode ()I LOOKUPSWITCH - 97: L1 - default: L2 - L1 - FRAME APPEND [java/lang/String I] + 97: L2 + default: L3 + L2 + FRAME SAME Don't know about importance of this, and whether this was expected, but decided to mention. ------------- Marked as reviewed by godin (Author). PR: https://git.openjdk.java.net/jdk/pull/3863 From erikj at openjdk.java.net Thu May 27 18:10:07 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 May 2021 18:10:07 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: On Thu, 27 May 2021 17:45:40 GMT, Nikita Gubarkov wrote: >> 8267706: bin/idea.sh tries to use cygpath on WSL > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > 8267706: Break long line in make/ide/idea/jdk/idea.gmk Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From forax at openjdk.java.net Thu May 27 18:22:13 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 27 May 2021 18:22:13 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. > - Correcting LineNumberTable for rule switches. > - Merging master into JDK-8262891 > - Fixing various error-related bugs. > - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. > - Reflecting recent spec changes. > - Reflecting review comments. > - Reflecting review comments on SwitchBootstraps. > - Trailing whitespaces. > - Cleanup, reflecting review comments. > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 > > I've updated the code to produce better/more useful LineNumberTable for rule switches. > > @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries +1 > [...] > Don't know about importance of this, and whether this was expected, but decided to mention. Look likes a mistake for me, you only need a StackFrame in front of the call to invokedynamic if it's the target of a goto and in your example, there is no guard so no backward goto. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From godin at openjdk.java.net Thu May 27 18:31:09 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Thu, 27 May 2021 18:31:09 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 18:19:38 GMT, R?mi Forax wrote: > in your example, there is no guard so no backward goto @forax btw this example is not about switch pattern matching - it is about already existing string switch, where indy not involed ? void example(java.lang.String); descriptor: (Ljava/lang/String;)V flags: (0x0000) Code: stack=2, locals=4, args_size=2 0: aload_1 1: astore_2 2: iconst_m1 3: istore_3 4: aload_2 5: invokevirtual #7 // Method java/lang/String.hashCode:()I 8: lookupswitch { // 1 97: 28 default: 39 } 28: aload_2 29: ldc #13 // String a 31: invokevirtual #15 // Method java/lang/String.equals:(Ljava/lang/Object;)Z 34: ifeq 39 37: iconst_0 38: istore_3 39: iload_3 40: lookupswitch { // 1 0: 60 default: 68 } 60: getstatic #19 // Field java/lang/System.out:Ljava/io/PrintStream; 63: ldc #13 // String a 65: invokevirtual #25 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 68: return LineNumberTable: line 3: 0 line 5: 60 line 7: 68 StackMapTable: number_of_entries = 5 frame_type = 253 /* append */ offset_delta = 4 locals = [ class java/lang/String, int ] frame_type = 23 /* same */ frame_type = 10 /* same */ frame_type = 20 /* same */ frame_type = 249 /* chop */ offset_delta = 7 ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From weijun at openjdk.java.net Thu May 27 20:16:25 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 27 May 2021 20:16:25 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v5] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - move one annotation to new method - merge from master, two files removed, one needs merge - keep only one systemProperty tag - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java - feedback from Sean, Phil and Alan - add supresswarnings annotations automatically - manual change before automatic annotating - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal ------------- Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04 Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Fri May 28 02:01:19 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 28 May 2021 02:01:19 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v5] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Two files were removed by JEP 403 and JEP 407, respectively. One method in `XMLSchemaFactory.java` got [its own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429) `@SuppressWarnings` and have to be merged with the one here. Another file `ResourceBundle.java` had a portion of a method extracted into a [new method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175) and the annotation must be moved there. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From hannesw at openjdk.java.net Fri May 28 08:19:33 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 28 May 2021 08:19:33 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v2] In-Reply-To: References: Message-ID: > This adds a new kind of summary list for new API added in specific releases, and adds information to the deprecated API list about elements that were deprecated in the given releases. > > The changes to the code are relatively minor thanks to the existing infrastructure for summary list pages, which was extended by adding the `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in order to generate tabbed tables. > > One important area that needs to be reviewed is the addition of resources in `standard.properties`. A relatively big share of discussion and effort went into shaping the UI messages. > > The build system change adds options to generate API changes for all releases after JDK 11, with "New API since JDK 11" as page title for the new API page. I uploaded the generated documentation here: > > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html > http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: JDK-8263468: automate build integration ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4209/files - new: https://git.openjdk.java.net/jdk/pull/4209/files/e81532b2..2a9dbbbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4209&range=00-01 Stats: 10 lines in 4 files changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4209/head:pull/4209 PR: https://git.openjdk.java.net/jdk/pull/4209 From hannesw at openjdk.java.net Fri May 28 08:23:12 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 28 May 2021 08:23:12 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v2] In-Reply-To: References: <5W5ac34XHsQZnwO6IGzpjIRsJwCoW7x3c385DeSJ7Ds=.e2759219-2f78-4ec9-b2a5-0136ab64d6e2@github.com> Message-ID: On Thu, 27 May 2021 13:32:36 GMT, Erik Joelsson wrote: >> Yes, there are a few things, but in the build itself, we are down to a single config file today, so I would really appreciate if this could be figured out. I can provide the implementation for generating this, but I need to understand what the expected pattern is. From what I can see, it looks like $(sequence N, M) where N is the last LTS+1 and M is current JDK version. Then the string has "JDK N" in it. M is already well defined, so the only new input here is N, which we could move to the version numbers config file (make/conf/version-numbers.conf). Something like DEFAULT_VERSION_DOCS_API_SINCE=11. There is some additional boilerplate needed, and the sequence macro of course, but does this sound reasonable to you? > > We actually have a sequence macro already, so generating the list can be done like this: > > $(call CommaList,$(call sequence 12, 17)) > > Or if what you have is 11 and 17: > > $(call CommaList, $(filter-out 11, $(call sequence 11, 17))) Thanks for the help and for providing all the pieces, Erik! I just added a new commit and I think I got everything working. ------------- PR: https://git.openjdk.java.net/jdk/pull/4209 From jlahoda at openjdk.java.net Fri May 28 11:08:42 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 11:08:42 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v6] In-Reply-To: References: Message-ID: <9siiRgAecypi4U4cS7zXk2MwDk3EsPZwvUtEMaGTJz8=.ed45bb06-c5d8-4efd-a35a-7e8a566858dd@github.com> > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Avoiding unnecessary StackMap point. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/fd748501..a57d306b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=04-05 Stats: 76 lines in 2 files changed: 72 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri May 28 11:08:43 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 11:08:43 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 18:28:13 GMT, Evgeny Mandrikov wrote: >>> > I've updated the code to produce better/more useful LineNumberTable for rule switches. >>> >>> @lahodaj I re-tested previous example and tested few others. Now everything seems to be good with `LineNumberTable` entries +1 >>> >> [...] >>> Don't know about importance of this, and whether this was expected, but decided to mention. >> >> Look likes a mistake for me, you only need a StackFrame in front of the call to invokedynamic if it's the target of a goto and in your example, there is no guard so no backward goto. > >> in your example, there is no guard so no backward goto > > @forax btw this example is not about switch pattern matching - it is about already existing string switch, where indy not involed ? > > > void example(java.lang.String); > descriptor: (Ljava/lang/String;)V > flags: (0x0000) > Code: > stack=2, locals=4, args_size=2 > 0: aload_1 > 1: astore_2 > 2: iconst_m1 > 3: istore_3 > 4: aload_2 > 5: invokevirtual #7 // Method java/lang/String.hashCode:()I > 8: lookupswitch { // 1 > 97: 28 > default: 39 > } > 28: aload_2 > 29: ldc #13 // String a > 31: invokevirtual #15 // Method java/lang/String.equals:(Ljava/lang/Object;)Z > 34: ifeq 39 > 37: iconst_0 > 38: istore_3 > 39: iload_3 > 40: lookupswitch { // 1 > 0: 60 > default: 68 > } > 60: getstatic #19 // Field java/lang/System.out:Ljava/io/PrintStream; > 63: ldc #13 // String a > 65: invokevirtual #25 // Method java/io/PrintStream.println:(Ljava/lang/String;)V > 68: return > LineNumberTable: > line 3: 0 > line 5: 60 > line 7: 68 > StackMapTable: number_of_entries = 5 > frame_type = 253 /* append */ > offset_delta = 4 > locals = [ class java/lang/String, int ] > frame_type = 23 /* same */ > frame_type = 10 /* same */ > frame_type = 20 /* same */ > frame_type = 249 /* chop */ > offset_delta = 7 @Godin thanks for noticing the unnecessary point in the StackMap! I've limited the entry to only be present for pattern matching switches, so ordinary switches should now look as before. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri May 28 11:36:10 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 28 May 2021 11:36:10 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 10:38:08 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. >> - Correcting LineNumberTable for rule switches. >> - Merging master into JDK-8262891 >> - Fixing various error-related bugs. >> - Avoiding fall-through from the total case to a synthetic default but changing total patterns to default. >> - Reflecting recent spec changes. >> - Reflecting review comments. >> - Reflecting review comments on SwitchBootstraps. >> - Trailing whitespaces. >> - Cleanup, reflecting review comments. >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/083416d3...fd748501 > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1657: > >> 1655: >> 1656: try { >> 1657: boolean enumSwitch = (seltype.tsym.flags() & Flags.ENUM) != 0; > > This is getting convoluted enough that an enum on the AST (e.g. SwitchKind) might be helpful to save some of these classification properties - which I imagine we have to redo at some point later (e.g. in Lower/TransPattern). I'm ok with fixing in a followup issue. Thanks Maurizio. Yes, some of the logic is partly repeated elsewhere, but I need to investigate how to improve that. I've filled: https://bugs.openjdk.java.net/browse/JDK-8267929 ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From erikj at openjdk.java.net Fri May 28 12:44:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 28 May 2021 12:44:03 GMT Subject: RFR: JDK-8263468: New page for "recent" new API [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 08:19:33 GMT, Hannes Walln?fer wrote: >> This adds a new kind of summary list for new API added in specific releases, and adds information to the deprecated API list about elements that were deprecated in the given releases. >> >> The changes to the code are relatively minor thanks to the existing infrastructure for summary list pages, which was extended by adding the `getTableCaption` and `addTableTabs` methods to `SummaryListWriter.java` in order to generate tabbed tables. >> >> One important area that needs to be reviewed is the addition of resources in `standard.properties`. A relatively big share of discussion and effort went into shaping the UI messages. >> >> The build system change adds options to generate API changes for all releases after JDK 11, with "New API since JDK 11" as page title for the new API page. I uploaded the generated documentation here: >> >> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/new-list.html >> http://cr.openjdk.java.net/~hannesw/8263468/api-pr.00/deprecated-list.html > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8263468: automate build integration Build changes look great! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4209 From github.com+9004656+yaaz at openjdk.java.net Fri May 28 19:57:26 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Fri, 28 May 2021 19:57:26 GMT Subject: Integrated: 8267706: bin/idea.sh tries to use cygpath on WSL In-Reply-To: References: Message-ID: <5fGbEK82GLJFg3mkT2fPEpjVena3PplrG_MMU3V_iAU=.3fc19daa-e42a-4979-a53c-574d826945b7@github.com> On Tue, 25 May 2021 16:37:30 GMT, Nikita Gubarkov wrote: > 8267706: bin/idea.sh tries to use cygpath on WSL This pull request has now been integrated. Changeset: 964bac9e Author: Nikita Gubarkov Committer: Alexey Ushakov URL: https://git.openjdk.java.net/jdk/commit/964bac9e38460df4bd1ad9d25136d5e9743028dd Stats: 672 lines in 14 files changed: 71 ins; 498 del; 103 mod 8267706: bin/idea.sh tries to use cygpath on WSL Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From maxim.kartashev at jetbrains.com Mon May 31 10:09:49 2021 From: maxim.kartashev at jetbrains.com (Maxim Kartashev) Date: Mon, 31 May 2021 13:09:49 +0300 Subject: PR for 8265431: Add -fdelete-null-pointer-checks to clang builds Message-ID: Hello All, I'd appreciate it very much if someone could take a look at my PR: https://github.com/openjdk/jdk/pull/4166 Thanks in advance, Maxim. From jlahoda at openjdk.java.net Mon May 31 13:49:56 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 31 May 2021 13:49:56 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v7] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision: - Fixing tests. - Total pattern dominates the null pattern. - Properly report errors for pattern+default clash. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/a57d306b..a49b6109 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=05-06 Stats: 52 lines in 6 files changed: 45 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From weijun at openjdk.java.net Mon May 31 15:02:57 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 31 May 2021 15:02:57 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: default behavior reverted to allow ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04-05 Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Mon May 31 15:09:27 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 31 May 2021 15:09:27 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> Message-ID: On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > default behavior reverted to allow New commit pushed. The default behavior is now reverted to be equivalent to `-Djava.security.manager=allow`. No warning will be shown when the system property is set to "allow", "disallow", or not set. A new test is added to check these warning messages. Some tests are updated to match the new behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From lancea at openjdk.java.net Mon May 31 16:24:24 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 31 May 2021 16:24:24 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> Message-ID: <95Pzw60HuW83TYfd9Dogs6AdG0GDq0Ajh8McoTvRhJU=.37e0db8a-8670-408f-81cd-b5d30ea724ce@github.com> On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > default behavior reverted to allow Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073