JDK-8299801 : Numerical computation differences between and JDK17 JDK8
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 17.0.5
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2023-01-05
  • Updated: 2024-04-29
Related Reports
Relates :  
JDK-8266524 - javac changes for JEP 306
Description
ADDITIONAL SYSTEM INFORMATION :
The bug appears on both tested hardware plaforms:
* Windows 11 running on Intel(R) Core(TM) i7-10875H CPU 
* Linux CentOS distribution  3.10.0-1062.4.1.el7.x86_64 Intel(R) Xeon(R) CPU E5-2680

A DESCRIPTION OF THE PROBLEM :
I'am running an apache Math Common optimizer named LevenbergMarquardtOptimizer. Goal is to find parameters to a custom harmonic + polynomial model.
Using same exact input data lead the optimizer : 
* Converge on Java 8 with parameters of the model are found
* Does not converge on Java 17 

There is no crash just a divergence in numerical results.
I was wondering if JEP-306 would be the cause, but it seems that strictfp is by default enforced in Java 8 on my platform without having to specify the strictfp keyword, as described in a comment by Joe Darcy inhttps://bugs.openjdk.org/browse/JDK-8266524

In any case we are wondering what is the cause of this divergence, is it a know behavior ?

REGRESSION : Last worked in version 8u351

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I have a unit test to reproduce the issue. I first run it with Java 8 environnement (compile + runtime=Java8) then on Java 17 environment.

I just pushed on github a minimalistic reproducible example. You can find it here
https://github.com/gjevardat/ReproduceFloatingPointBug.git

Clone the project and run the unit test named TimeSeriesModelFitterBugTest. I ran it in eclipse as a Junit5 test.

To see the difference of behavior just switch the java.version property from 1.8 to 17 in the pom.xml.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would expect same result on both JDK's.
ACTUAL -
Results are not similar. In one case the apache math common LevenbergMarquardtOptimizer converges in the other case it does not.

---------- BEGIN SOURCE ----------
Unfortunately due the non trivial code that is used, it is difficult to provide a minimal running example.  If necessary and if this problem is not known or not obvious we can put extra effort to extract a compilable code that show case the problem
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Non workaround

FREQUENCY : always
Comments
First, it is exceedingly unlikely that the change in JEP 306 caused the observed difference in behavior. This is unlikely for several reasons, the computation range where strictfp and default-fp differ are in portion of the subnormal range and the strictfp / default-fp difference only occurs when the legacy x87 floating-point instructions are used rather than SSE. Additionally, testing after the bug was submitted shows the lack of convergence occurs on JDK 11 which does not have JEP 306. Without benefit of a detailed investigation, my guess is that use java.lang.Math methods elsewhere is causing the difference in behavior. The implementation of various java.lang.Math methods, including sin, cos, tan, and exp, have platform-specific optimized intrinics that can and do vary by JDK. To get cross-JDK reproducibility and rule out this cause, use java.lang.StrictMath instead.
09-01-2023
Issue is reproduced. Testcase works fine with JDK 8 but throws the apache math common LevenbergMarquardtOptimizer converges exception error with JDK 11 and above. OS: Windows 10 JDK 8u351: Pass JDK 11: Fail JDK 17: Fail JDK 19: Fail ILW = issue in GA build (regression), reproducible with single test , no workaround available = HLM = P3 Moving it to dev team for further analysis.
09-01-2023