[15] RFR (M): 8136414: Large performance penalty declaring a method strictfp on strict-only platforms

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Fri Feb 7 09:37:53 UTC 2020


http://cr.openjdk.java.net/~vlivanov/8136414/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8136414

After JDK-7175279 [1] landed in the repo, it becomes possible to relax 
constrains on inlining between strict FP and non-strict FP methods on 
x86-64.

Since x86-64 doesn't use x87 anymore, the platform becomes strict-only 
and it's safe to mix strict and non-strict FP code.

The actual fix is a tiny change in doCall.cpp [2].

The rest is a refactoring which regularizes and cleans up related code:

   * removes RoundFPResults and UseStrictFP develop flags;

   * migrate all the checks to strict_fp_requires_explicit_rounding / 
pd_strict_fp_requires_explicit_rounding which are set true only on x86-32;

   * move related UseSSE checks to x86-specific code (or even x86-32 if 
UseSSE <= 2 is requires);

Testing: hs-precheckin-comp, tier1-4

Thanks!

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-7175279

[2] src/hotspot/share/opto/doCall.cpp

-  // Do not inline strict fp into non-strict code, or the reverse
-  if (caller->is_strict() ^ callee->is_strict()) {
+  // If explicit rounding is required, do not inline strict into 
non-strict code (or the reverse).
+  if (Matcher::strict_fp_requires_explicit_rounding &&
+      caller->is_strict() != callee->is_strict()) {
      allow_inline = false;
    }


More information about the hotspot-compiler-dev mailing list