Re: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines [v2]
> 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=4062=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4062=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
Re: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines
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:sh...@redhat.com) on > [build-dev](mailto:build-...@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
Re: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines
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
Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal
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
Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v4]
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.bur...@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
Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal
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
RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal
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=4073=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
Integrated: 8267112: JVMCI compiler modules should be kept upgradable
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
Re: RFR: 8267112: JVMCI compiler modules should be kept upgradable
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
Re: RFR: 8267112: JVMCI compiler modules should be kept upgradable
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
Re: RFR: 8267112: JVMCI compiler modules should be kept upgradable
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
Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2]
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 fo...@github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/3863
Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2]
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
Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v2]
> 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=3863=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3863=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
Re: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines
On 5/17/21 7:30 PM, erik.joels...@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
Re: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines
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
Re: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines
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
Re: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current
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
Re: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines
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
RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current
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=4069=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
Re: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines
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
Re: RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines
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
RFR: 8267246: -XX:MaxRAMPercentage=0 is unreasonable for jtreg tests on many-core machines
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=4062=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
Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v4]
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.bur...@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
