JDK-6850611 : int / long arithmetic seems to be broken in 1.6.0_14 HotSpot Server VM (Win XP)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6u14
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2009-06-12
  • Updated: 2011-02-16
  • Resolved: 2009-06-24
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode)

The same behavior is also reproducible on
Linux (32 bit) with 1.6.0_14.

It is further reproducible with 1.7.0-ea (build 1.7.0-ea-b59) on
both Win XP (32 bit) and Linux (32 bit).


FULL OS VERSION :
Microsoft Windows XP [Version 5.1.2600] (SP3)

EXTRA RELEVANT SYSTEM CONFIGURATION :
CPU: Intel T7200 Dual Core @ 2 GHz

A DESCRIPTION OF THE PROBLEM :

Summing all ints from Integer.MIN_VALUE up to Integer.MAX_VALUE - 1 into a long variable gives different results when run in the server VM as opposed to the client VM.

Doing this 10 times gives even 2 different results for the server VM!

This doesn't happen in the client VM or in interpreted (-Xint) mode.

(I checked the behavior for the older server VMs: 1.6.0_12, 1.5.0_17 and 1.4.2_17 - all of them deliver the "expected" result shown below)

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the test case (test.TestCase) with the 1.6.0_14 server VM on Windows XP

My command line is: "F:\Develop>F:\Java\sun-jdk1.6.0_14\bin\java -server test.TestCase"

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected results:

sum: -4294967295
sum: -4294967295
sum: -4294967295
sum: -4294967295
sum: -4294967295
sum: -4294967295
sum: -4294967295
sum: -4294967295
sum: -4294967295
sum: -4294967295

Actual results:

sum: -32212254615
sum: -36507221880
sum: -36507221880
sum: -36507221880
sum: -36507221880
sum: -36507221880
sum: -36507221880
sum: -36507221880
sum: -36507221880
sum: -36507221880

Note, the first output is differs from the rest. All of them seem to be wrong.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package test;

public class TestCase {

	public static void main(String[] args) {
		test();
	}

	private static void test() {
		for (int j = 0; j < 10; ++j) {
			long x = 0;
			for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; ++i) {
				x += i;
			}
			System.out.println("sum: " + x);
		}
	}
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None (apart from goin back to 1.6.0 Update 12 where this doesn't happen)

Release Regression From : 6u13
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION Yes, it is a duplicate of 6186134. The problem is the Canonicalization for a counted loop. Here is the piece of code in "is_counted_loop" in loopnode.cpp: // If compare points to incr, we are ok. Otherwise the compare // can directly point to the phi; in this case adjust the compare so that // it points to the incr by adjusting the limit. if( cmp->in(1) == phi || cmp->in(2) == phi ){ // if(limit->is_Con() && limit->get_int() == max_jint) // return NULL; limit = gvn->transform(new (C, 3) AddINode(limit,stride)); } It transforms from something like "if( i < limit) " to "if(i+stride < limit+stride". The two lines of commented codes is what I added. It can hide the problem for known limit as max_jint, but note a solution for the int overflow problem. I am still trying to understand why counted loops should have such format for loop exit comparison (most possibly iteration splitting requirements ??) I am closing this one, and working on 6186134.
24-06-2009

EVALUATION Tom's RPO changes converted the inner loop into counted loop which uses incorrect range check because of 6186134 bug.
24-06-2009

EVALUATION The bug shows up with the fix for 6384206 between HS14b05 and HS14b06. I'm not sure if the changes for 6384206 really cause the bug or just produce it and it's actually a duplicate of e.g. 6186134. Tom or Changpeng should know more about this.
19-06-2009