JEP 306: Restore Always-Strict Floating-Point Semantics

AuthorJoseph D. Darcy
OwnerJoe Darcy
Componentspecification / language
Discussionhotspot dash dev at openjdk dot java dot net, core dash libs dash dev at openjdk dot java dot net
Reviewed byBrian Goetz, Mikael Vidstedt
Endorsed byMikael Vidstedt
Created2017/02/27 15:51
Updated2020/05/29 21:54


Rather than have both strict floating-point semantics (strictfp) and subtly different default floating-point semantics in the language and VM, make floating-point operations consistently strict. This would restore the original floating-point semantics to the language and VM, matching the semantics before the introduction of strict and default floating-point modes in Java SE 1.2.


Having a consistent set of floating-point semantics will ease development of numerically-sensitive libraries, including java.lang.Math and java.lang.StrictMath, and provide more regularity in a tricky aspect of the platform.


Defining any sort of "fast-fp" or "loose-fp" (c.f. JSR 84: Floating Point Extensions) is out of scope for this JEP.


The impetus for changing the default floating-point semantics of the platform in the late 1990's 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. Matching the results in the absence of overflow or underflow could be achieved with much less overhead and that is roughly what is allowed by the revised default floating-point semantics introduced in Java SE 1.2.

However, the SSE2 (Streaming SIMD Extensions 2) extensions, shipped in Pentium 4 and later processors starting circa 2001, could support strict JVM floating-point operations in a straightforward manner without undue overhead.

Since Intel and AMD have both long supported SSE2 and later extensions which allow natural support for strict floating-point semantics, the technical motivation for having a default floating-point semantics different than strict is no longer present.


The interfaces this JEP would modify include the Java Language Specification in its coverage of floating-point values (see JLS 8th edition section 4.2.3 Floating-Point Types, Formats, and Values and section 15.4 FP-strict Expressions) and similar sections of the Java Virtual Machine Specification (see JVMS 8th edition section 2.3.2 Floating-Point Types, Values Sets, and Values, section 2.8.2 Floating-Point Modes, and section 2.8.3 Value Set Conversion). Most of the implementation changes in the JDK would be to the HotSpot virtual machine to never run in a floating-point mode which allowed the extended exponent value set; such a mode is mandated to be present for strictfp operations.


All existing numerical tests would remain valid with this change since this change always uses one of the currently allowable modes of operation.

Existing Java source tests using strictfp could be replicated without the modifier.

Risks and Assumptions

The proposed specification changes are low-risk. The platform's original semantics are restored and strict-only was always an allowable implementation option.