JDK-8210858 : AArch64: remove Math.log intrinsic
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,21,22,23
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2018-09-18
  • Updated: 2024-02-01
  • Resolved: 2024-01-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 23
23 b08Fixed
Related Reports
Relates :  
JDK-8215133 - AARCH64: disable Math.log intrinsic publishing
Relates :  
JDK-8211105 - AArch64: Disable cos/sin and log intrinsics in jdk11u pending fix
Relates :  
JDK-8196402 - AARCH64: create intrinsic for Math.log
Description
Remove Math.log instrinsic (it is already disabled). 

Reason: the available implementation gave incorrect results: 

public class LogTest {
    public static void main(String[] args) {
        double x = 4.9E-324;
        System.out.println(Math.log(x));
        System.out.println(StrictMath.log(x));
    }
}

Should be -744.4400719213812, result is -710.989276736877.
Correct on Intel x86.

Second reason: We do not have proof of the monotonicity for the patch of this intrinsic.
Comments
Changeset: 422020c4 Author: Tobias Holenstein <tholenstein@openjdk.org> Date: 2024-01-29 08:37:06 +0000 URL: https://git.openjdk.org/jdk/commit/422020c4d691f3ad4c7af4fc2c60e7ada66734e0
29-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17480 Date: 2024-01-18 08:58:20 +0000
18-01-2024
Thanks! I will remove it then
12-10-2023
I think you should remove the intrinsic. Reasons: If we're going to enable the intrinsic, we need to ensure that it can meet the Java specification. That specification says: "The computed result must be within 1 ulp of the exact result. Results must be semi-monotonic... whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation" Ferguson and Brightman https://web.stanford.edu/class/ee486/doc/ferguson1991.pdf provided techniques that can be used to prove that an approximation is monotonic in this sense, but I think that proof requires two extra guard bits before the final rounding. I don't believe that any proof of the monotonicity of this intrinsic is likely to be forthcoming.
11-10-2023
[~aph] Since JDK-8215133 vmIntrinsics::_dlog is disabled with a comment "Disabled until JDK-8210858 is fixed". Do you think vmIntrinsics::_dlog should be fixed? Otherwise I would remove vmIntrinsics::_dlog completely.
13-09-2023
[~dpochepk], any plans to pick this back up? See also JDK-8302736.
17-02-2023
Recently there was a proposal to use Arm's fast intrinsics library in OpenJDK, but that library has no guarantees of monotonicity. For that reason, given that monotonicity is required by the JLS, we had to abandon the proposal. That might well be a problem here too.
26-02-2022
I would be good to have it in JDK 12. I'm not sure review process will be short enough for that, so, I've set tbd. Currently, fix is going through internal review process. Probably will publish it soon. Will push it to 12 if possible,
29-11-2018
Hi @Dmitrij Pochepko, Request your help. (Please note based on JDK 12 schedule I am checking possible deferral candidates of JDK 12 hotspot/compiler tasks - http://openjdk.java.net/projects/jdk/12/) Are you planning 8210858 fix to be in JDK 12? (else you may please change the 'Fix Version' in JBS to 'tbd' for now and update with a correct version later when available). Thanks.
29-11-2018
Patch is ready. Initialization sequence for small values was affected: diff -r 2a51125b2794 src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp Tue Sep 18 21:47:14 2018 -0700 +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp Fri Sep 21 01:57:59 2018 +0300 @@ -283,20 +283,26 @@ br(LE, CHECK_CORNER_CASES); bind(CHECKED_CORNER_CASES); // all corner cases are handled frecpe(vtmp5, vtmp5, S); // vtmp5 ~= 1/vtmp5 lsr(tmp2, rscratch1, 48); movz(tmp4, 0x77f0, 48); fmovd(vtmp4, 1.0d); + mov(tmp5, 0x3FE0); movz(tmp1, INF_OR_NAN_PREFIX, 48); - bfm(tmp4, rscratch1, 0, 51); // tmp4 = 0x77F0 << 48 | mantissa(X) - // vtmp1 = AS_DOUBLE_BITS(0x77F0 << 48 | mantissa(X)) == mx - fmovd(vtmp1, tmp4); subw(tmp2, tmp2, 16); subs(zr, tmp2, 0x8000); br(GE, SMALL_VALUE); bind(MAIN); + bfm(tmp4, rscratch1, 0, 51); // tmp4 = 0x77F0 << 48 | mantissa(X) + fmovs(tmp3, vtmp5); // int intB0 = AS_INT_BITS(B); - mov(tmp5, 0x3FE0); +fmovd(vtmp1, tmp4); mov(rscratch1, 0xffffe00000000000); andr(tmp2, tmp2, tmp1, LSR, 48); // hiWord & 0x7FF0 sub(tmp2, tmp2, tmp5); // tmp2 = hiWord & 0x7FF0 - 0x3FE0 @@ -334,13 +340,16 @@ fmovd(vtmp1, tmp2); fmuld(vtmp0, vtmp1, v0); fmovd(vtmp1, vtmp0); - umov(tmp2, vtmp1, S, 3); + umov(tmp2, vtmp1, H, 3); + mov(tmp5, 0x47F0); orr(vtmp0, T16B, vtmp0, vtmp4); ushr(vtmp5, T2D, vtmp0, 27); ushr(vtmp5, T4S, vtmp5, 2); frecpe(vtmp5, vtmp5, S); shl(vtmp1, T2D, vtmp1, 12); ushr(vtmp1, T2D, vtmp1, 12); + fmovd(rscratch1, vtmp1); b(MAIN); } However, I'd prefer to create better documentation and re-check it . It'll take some time. In case of urgency this patch can be applied as is.
21-09-2018