RFR: 8276217: Harmonize StrictMath intrinsics handling
Andrew Haley
aph at openjdk.java.net
Mon Nov 1 13:11:08 UTC 2021
On Mon, 1 Nov 2021 11:23:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by giving failing intrinsics a second chance to match against the similar `Math` intrinsics. This has interesting consequence for matchers: we can match the native `StrictMath.sqrt` to non-native intrinsic for `Math.sqrt`. Interpreter would then have to disambiguate the two. It could be made simpler and more consistent.
>
> For `min`/`max` methods, `StrictMath` already delegates to `Math` methods, so we can just drop the intrinsics for them. `sqrt` is harder to delegate, because it is `native` and a part of public API, so we can instead do the proper special intrinsic for it.
>
> There seem to be no performance regressions with this patch at least on Linux x86_64:
>
>
> $ CONF=linux-x86_64-server-release make test TEST="micro:StrictMathBench"
>
> Benchmark Mode Cnt Score Error Units
>
> ### Before
>
> StrictMathBench.minDouble thrpt 4 230921.558 ± 234.238 ops/ms
> StrictMathBench.minFloat thrpt 4 230932.303 ± 126.721 ops/ms
> StrictMathBench.minInt thrpt 4 230917.256 ± 73.008 ops/ms
> StrictMathBench.minLong thrpt 4 194460.828 ± 178.079 ops/ms
>
>
> StrictMathBench.maxDouble thrpt 4 230983.180 ± 161.211 ops/ms
> StrictMathBench.maxFloat thrpt 4 230969.290 ± 277.500 ops/ms
> StrictMathBench.maxInt thrpt 4 231033.581 ± 200.015 ops/ms
> StrictMathBench.maxLong thrpt 4 194590.744 ± 114.295 ops/ms
>
>
> StrictMathBench.sqrtDouble thrpt 4 230722.037 ± 2222.080 ops/ms
>
> ### After
>
> StrictMathBench.minDouble thrpt 4 230976.625 ± 67.338 ops/ms
> StrictMathBench.minFloat thrpt 4 230896.021 ± 270.434 ops/ms
> StrictMathBench.minInt thrpt 4 230859.741 ± 403.147 ops/ms
> StrictMathBench.minLong thrpt 4 194456.673 ± 111.557 ops/ms
>
> StrictMathBench.maxDouble thrpt 4 230890.776 ± 89.924 ops/ms
> StrictMathBench.maxFloat thrpt 4 230918.334 ± 63.160 ops/ms
> StrictMathBench.maxInt thrpt 4 231059.128 ± 51.224 ops/ms
> StrictMathBench.maxLong thrpt 4 194488.210 ± 495.224 ops/ms
>
> StrictMathBench.sqrtDouble thrpt 4 231023.703 ± 247.330 ops/ms
>
>
> Additional testing:
> - [x] `StrictMath` benchmarks
> - [x] Linux x86_64 fastdebug `tier1`
So we have _dsqrt and_dsqrt_strict, which must be functionally identical, but we provide both names because they're part of a public API. I think this deserves an explanatory comment in the code.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6184
More information about the core-libs-dev
mailing list