3

JEP 306, implemented in Java 17, provides always-strict floating point semantics, deprecating the strictfp flag. Does this mean that java.lang.Math can be counted on to behave exactly the same as the analogous methods in StrictMath (i.e., that java.lang.Math methods can no longer be replaced by the JVM with intrinsics as used to be allowed)? Does it also mean that there should no longer be any differences in floating point math results among different architectures, no matter which library is used?

I'm curious if I'm misunderstanding the new Java 17 feature, since we do see differences in today's code between Apple Silicon vs Intel.

Joshua Goldberg
  • 5,059
  • 2
  • 34
  • 39
  • 2
    What are your examples? – DuncG Jul 13 '23 at 07:59
  • +1, I appreciate that @DuncG, but will not be able to answer right away. I'll need to dig some to find sub-calculations where differences are coming up in a complex application. I'd even need to bring in another team member because I only have access to intel at the moment. We do see consistent differences in end results, though. – Joshua Goldberg Jul 13 '23 at 16:16
  • 1
    Being strict and using intrinsics (i.e. dedicated FPU instructions) is not a contradiction. It’s all about not using the old x87 FPU but SSE2 which has been introduced 2 decades ago. In case of `java.lang.Math` and the reference implementation, this is the case [since Java 15](https://bugs.openjdk.org/browse/JDK-7175279). This applies to the HotSpot JVM and all implementations building on it or following suit. But as long as [the specification](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Math.html) says that differences are allowed, you have to be prepared for them… – Holger Jul 14 '23 at 07:03

0 Answers0