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.
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
|