Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8175916

JEP 306: Restore Always-Strict Floating-Point Semantics


    • Type: JEP
    • Status: Candidate
    • Priority: P4
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: specification
    • Labels:
    • Author:
      Joseph D. Darcy
    • JEP Type:
    • Exposure:
    • Subcomponent:
    • Scope:
    • Discussion:
      hotspot dash dev at openjdk dot java dot net, core dash libs dash dev at openjdk dot java dot net
    • Effort:
    • Duration:
    • JEP Number:



      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.


          Issue Links



              • Assignee:
                darcy Joe Darcy
                darcy Joe Darcy
                Joe Darcy
                Reviewed By:
                Brian Goetz, Mikael Vidstedt
                Endorsed By:
                Mikael Vidstedt
              • Votes:
                0 Vote for this issue
                10 Start watching this issue


                • Created: