RFR: 8265768 [aarch64] Use glibc libm impl for dlog,dlog10,dexp iff 2.29 or greater on AArch64.

[Tobias Hartmann]

On Fri, 1 Apr 2022 15:38:36 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Will this patch change `java.lang.Math`, `java.lang.StrictMath` or both? I've noticed differences in iterative machine learning algorithms using exp & log across different JVMs and architectures which we try to track in [Tribuo](https://github.com/oracle/tribuo) by recording the JVM & arch in our model provenance objects. If this patch is integrated will there be an easy way to get (e.g. from `System.getProperty`) what implementation of exp is in use by the current JVM? Otherwise I won't be able to notify users that the model may not reproduce if they rerun the same computation on different versions of Linux with the same JVM & architecture.
>
>> Will this patch change `java.lang.Math`, `java.lang.StrictMath` or both? I've noticed differences in iterative machine learning algorithms using exp & log across different JVMs and architectures which we try to track in [Tribuo](https://github.com/oracle/tribuo) by recording the JVM & arch in our model provenance objects.
> 
> Exactly so, and that is why this patch was never integrated. This was only ever going to be about `java.lang.Math`, but we foundered on the rock of monotonicity. Here's the spec:
> 
> "most methods with more than 0.5 ulp errors are required to 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. Not all approximations that have 1 ulp accuracy will automatically meet the monotonicity requirements."
> 
> We couldn't guarantee we'd meet the monotonicity requirements if we used glibc libm, so this patch was, with some regret, abandoned.

@theRealAph Thanks for the summary. I closed the JBS issue as Won't Fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3510