JDK-8014296 : java/lang/Math/DivModTests.java should not compare pointers
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-05-09
  • Updated: 2013-06-18
  • Resolved: 2013-05-10
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.
JDK 8
8 b91Fixed
Related Reports
Relates :  
JDK-8014286 - failed java/lang/Math/DivModTests.java after 6934604 changes
Relates :  
JDK-6282196 - There should be Math.mod(number, modulo) methods
Description
I am working on Boxing elimination in Hotspot JIT and the java/lang/Math/DivModTests.java  fails like next:

bash-2.05b$ bin/java -d64 -Xcomp DivModTests
FAIL: Math.floorMod(3, 3) = 0 differs from Math.floor(x, y): 0
FAIL: Math.floorMod(2, 3) = 2 differs from Math.floor(x, y): 2
FAIL: Math.floorMod(1, 3) = 1 differs from Math.floor(x, y): 1
...
FAIL: Long.floorMod(-9223372036854775808, -1) = 0 is different than BigDecimal result: 0
Exception in thread "main" java.lang.RuntimeException: 51 errors found in DivMod methods.
        at DivModTests.main(DivModTests.java:48) 


The problem are next checks which compare boxing object (Integer or Long) with int (or long) value:

      140             if (fr != result) {

      243             if (fr != result) {

javac generates pointers compare for such cases:

119 fast_iload #8
121 invokestatic 18 <java/lang/Integer.valueOf(I)Ljava/lang/Integer;> 
124 aload_3
125 if_acmpeq 163

These checks will only pass if a value is in the range of boxing cache (as they are in the test) .
If 'result' is not in [-128,127] range the test will fail as above.
Comments
verified in b94
18-06-2013
Corrected to use equals() instead of ==. Changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c26e0d29249a
10-05-2013
It seems like a very easy mistake to make since autoboxing is hard to see in the source. Perhaps the compiler/tool chain should warn about using ==/!= with mixed primitive and object refs. Or the compiler should promote to equals() in that case.
10-05-2013