0

The strictfp keyword was introduced into Java with the Java virtual machine version 1.2 and its functionality was removed in JVM version 17. As of Java 17, IEEE 754 semantics is required, thus using this keyword has no effect.

But how to achieve the same result of IEEE 754 standard? Was it simply removed from the language?

felipe
  • 1,212
  • 1
  • 15
  • 27
  • 1
    From Java 17 version, strictfp keyword is NOT required explicitly as all floating point expressions are strictly evaluated. https://openjdk.org/jeps/306 – experiment unit 1998X Jul 12 '23 at 11:54
  • 2
    What exactly do you mean by "the same result"? Floating point semantics are always strict since java 17 ([see this JEP](https://openjdk.org/jeps/306)), making this keyword useless. – f1sh Jul 12 '23 at 11:54
  • 5
    “But how to achieve the same result?” — *Every* floating point arithmetic in Java 17 achieves the same result. That’s the whole point. Java 17 behaves as if `strictfp` was used everywhere. – Konrad Rudolph Jul 12 '23 at 11:54
  • @f1sh I changed the question thanks – felipe Jul 12 '23 at 11:59
  • 1
    You **always** get the behaviour as if you had previously used `strictfp` before. The thing that was removed was the option to *maybe* get non-strictfp behaviour if your JVM was implemented that way. – Joachim Sauer Jul 12 '23 at 12:01
  • @experimentunit1998X ok, so every calculation is strictly evaluated now? it's really interesting, doesnt this make any performance loss or something? – felipe Jul 12 '23 at 12:01
  • It might have been a factor 20 years ago, but it is not anymore. You can read the linked JEP for details on this. Quote: "_[...] stemmed from a bad interaction between the original Java language and JVM semantics and some unfortunate peculiarities of the x87 floating-point co-processor instruction set of the popular x86 architecture. Matching the exact floating-point semantics in all cases, including subnormal operands and results, required large overheads of additional instructions."_ – Zabuzard Jul 12 '23 at 12:01
  • On Intel based systems, the `strictfp` keyword was necessary to *reduce* the intermediate precision of floating point operations used internally by the CPU (basically, Intel uses extended precision). The change in Java 17 was to replace the Intel native floating point math operations with SSE2 calls (Pentium 4 and newer, around 2001). See [JEPS-306](https://openjdk.org/jeps/306). – Elliott Frisch Jul 12 '23 at 12:03
  • 1
    What part of _"As of Java 17, IEEE 754 semantics is required, thus using this keyword has no effect."_ is unclear? Did you think `strictfp` was something other than IEEE 754 semantics? – Mark Rotteveel Jul 12 '23 at 12:41
  • @MarkRotteveel it's unclear, if we don't use it how can we achive IEEE 754 similar standard, like same float point operations every processor? but as experimentunit1998X said all calculations are strictly evaluated now, so I understand we have similar feature to IEEE 754 by default now – felipe Jul 12 '23 at 15:47
  • `strictfp` **is** IEEE 754 behaviour, and that has now been made the default behaviour again, so you don't need to specify `strictfp` anymore to get the IEEE 754 behaviour, because since Java 17 you always get that. – Mark Rotteveel Jul 12 '23 at 17:29
  • @felipe Prior to Java 17, on Intel systems, Java would (by default) use 80 bit **extended** precision IEEE 754 because that is what the Intel floating point unit supported; on other platforms (like ARM, and IBM Power) it would use 64 bit precision IEEE 754. `strictfp` (when it did anything at all) limited Intel systems to 64 bit precision IEEE 754. It was always IEEE 754. And it only really mattered when you needed to reconcile with a non-Intel system (and with a large number of transactions). – Elliott Frisch Jul 12 '23 at 21:10
  • Aside from performance, I think people used to say there was a loss of accuracy with using strictfp, in exchange for the consistency. Does this mean that the more accurate, performant calculations are no longer available? – Joshua Goldberg Jul 13 '23 at 16:33

0 Answers0