JDK-6245564 : Problem with Hotspot C2-compiled code calling long to float conversion on US-III and IV in Java 1.5
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u2
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2005-03-24
  • Updated: 2011-12-14
  • Resolved: 2005-03-24
Related Reports
Duplicate :  
Description
Hotspot-compiled code on UltraSparcIII and IV can make bad conversions from long to float.  It passes arguments incorrectly to SharedRuntime::l2f .

Problem is in 1.5.0_02 and not in 1.4.2_07.

Simple testcase below. Problem output:

(5.10)$ java -server -Xcomp Test
result 0 = 40.0
result 1 = 1.71798757E11
result 2 = 1.71798757E11
result 3 = 1.71798757E11
...testcase continues (showing wrong answers)...

problem:	java -server -Xcomp Test
no problem: 	java -client -Xcomp Test

The testcase pauses for a keypress, for attaching debuggers.

Problem happens on US-III+ and US-IV, not on an Ultra-1, for example.

Testcase code below, attached is a version with additional comments.

----- start of testcase 
$ cat Test.java

class Test {

        float [] fresults  = new float[50];
        int fc = 0;

// variable names copied from SizeRequirements.java's expandedTile function:

        private  void smallTest (int allocated, long min, long pref, long max ) {
                float totalPlay = Math.min(allocated - pref, max - pref);
                fresults[fc] = totalPlay;
                fc++;
        }


        public Test() {

        for (int i=0; i<5; i++) {
                smallTest(88, 48, 48, 65582);
                smallTest(88, 48, 48, 65582);
                smallTest(88, 48, 48, 65582);
        }
        for (int i=0; i<15; i++) {
                System.out.println("result " + i + " = " + fresults[i]);
        }

        try {
                int x = System.in.read();
        } catch (Exception e) {
        }

        fc = 0;
        for (int i=0; i<5; i++) {
                smallTest(88, 48, 48, 65582);
                smallTest(88, 48, 48, 65582);
                smallTest(88, 48, 48, 65582);
        }
        for (int i=0; i<15; i++) {
                System.out.println("result " + i + " = " + fresults[i]);
        }

        } // end constructor

        public static void main(String [] args) {
                Test t = new Test();
        } // end main



} // end class



----- end of testcase 


This bug has a graphic side effect:

Swing menus are blank with -server -Xcomp in Java 1.5 on UltraSparcIII and IV.

.jpg attached.

Pull-down menus in Swing applications are blank in Java 1.5, if running with the JVM option -Xcomp.


Testcase:
java -server -Xcomp -jar ..../demo/jfc/SwingSet2/SwingSet2.jar

Workaround:

 .hotspot_compiler
exclude javax/swing/SizeRequirements expandedTile

----------------------------------------------------
###@###.### 2005-03-24 16:40:46 GMT

Comments
WORK AROUND Excluding the calling method from hotspot-compilation avoids the problem: interpreted code does the conversion differently. However, you have to have identified the line of code where your calculations are going wrong to do this, so this should not be seen to reduce the impact of this bug! There are ways to accidentally cure this problem, and it seems many apps will have done one of them by the time a method is hotspot-compiled and converts a long to a float. Those ways include, if the main method has done for example a Thread.sleep or System.out.println, then the problem does not occur. This confuses things - but it seems really to just be that in those cases we are not running the c2-compiled method! Attaching serviceability agent does not find the compiled code, although -XX:+PrintCompilation shows the method smallTest did get compiled. 64-bit mode (java -d64 -Xcomp) does not show the problem. ###@###.### 2005-03-24 16:40:46 GMT
24-03-2005