JDK-8136414 : Large performance penalty declaring a method strictfp on strict-only platforms
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-09-11
  • Updated: 2024-02-06
  • Resolved: 2020-02-11
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 15
15 b10Fixed
Related Reports
Blocks :  
Relates :  
Relates :  
Description
Java has two kinds of floating-point environments:

* FP-strict (methods declared strictfp, etc.) where floating-point operational semantics are fully specified

* non FP-strict (the default) where some variation is allowed in the exponent range of expressions, but not in fields.

The non-strict environment accommodates certain peculiarities of performing 32-bit float and 64-bit double calculations on the 80-bit registers of the x87 stack. However, on many hardware processors strictfp is a no-op since all the floating-point operations run strictly. These contexts where strictfp is a no-op would include x86 SSE2 and later instruction set extensions.

When there is no difference in code generated between strictfp and non-strictfp contexts, there should not be a large performance penalty to declaring code strictfp.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/698732b81e94 User: vlivanov Date: 2020-02-11 11:56:33 +0000
11-02-2020

Graal may be affected too.
08-03-2018

We hit FC for jdk 9. Will look on this in jdk 10.
09-05-2016