JDK-6513210 : Assignment of local variables does not work as expected in control flow
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-01-15
  • Updated: 2011-02-16
  • Resolved: 2007-01-16
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)


FULL OS VERSION :
Windows XP SP2

A DESCRIPTION OF THE PROBLEM :
It seems that Client HostSpot does not properly handle assignment expression of local variables when those variables are used in a complex control flow.

The test case attached below illustrates the problem.

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: No

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the test code below
2. Execute the code
     % java B


EXPECTED VERSUS ACTUAL BEHAVIOR :
In the test code below, RuntimeException should not be thrown, but client HostSpot throws.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.RuntimeException: 0 != 1
	at B._assert(B.java:4)
	at B.doTest(B.java:12)
	at B.main(B.java:26)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class B {
    private static void _assert(int actual, int expected){
	if (actual != expected){
	    throw new RuntimeException(actual + " != " + expected);
	}
    }

    protected static void doTest() {
	int a = 1;
	int b = 0;
	for (int i = 0; i < 2; i++){
	    _assert(b, i==0? 0 : 1);
	    boolean cont = true;
	    while (cont){
		cont = false;
		if (i == 0){
		    b = a;
		    a = 2;
		}
	    }
	}
	for (int i = 0; i < 1000; i++);
    }
    public static void main(String[] args) {
	for(int i = 0; i < 4; i++){
	    doTest();
	}
    }
}


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

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