United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4965430 : Inconsistent results when comparing string references

Details
Type:
Bug
Submit Date:
2003-12-09
Status:
Closed
Updated Date:
2004-04-30
Project Name:
JDK
Resolved Date:
2004-01-21
Component:
hotspot
OS:
solaris_8
Sub-Component:
compiler
CPU:
generic
Priority:
P1
Resolution:
Fixed
Affected Versions:
1.4.2_02
Fixed Versions:
1.4.2_05 (05)

Related Reports
Backport:

Sub Tasks

Description
A piece of code that is written as follows:

String s = "";
while (s == "") { }

...is seen to produce inconsistent results when it is embedded within a highly threaded program having thousands of lines of code.  Under IBM's VM, this always evaluates as TRUE.  With Sun's VM, the loop is occasionally ignored.

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.2_05
generic
tiger-beta2

FIXED IN:
1.4.2_05
tiger-beta2

INTEGRATED IN:
1.4.2_05
tiger-b35
tiger-beta2

VERIFIED IN:
1.4.2_05


                                     
2004-06-14
SUGGESTED FIX

--- subnode.cpp	Thu Dec 18 10:27:39 2003
***************
*** 547,558 ****
  
    // Unknown inputs makes an unknown result
    if( r0->singleton() ) {
!     jint bits0 = r0->get_con();
      if( r1->singleton() ) 
        return bits0 == r1->get_con() ? TypeInt::CC_EQ : TypeInt::CC_GT;
      return ( r1->_ptr == TypePtr::NotNull && bits0==0 ) ? TypeInt::CC_GT : TypeInt::CC;
    } else if( r1->singleton() ) {
!     jint bits1 = r1->get_con();
      return ( r0->_ptr == TypePtr::NotNull && bits1==0 ) ? TypeInt::CC_GT : TypeInt::CC;
    } else 
      return TypeInt::CC;
--- 547,558 ----
  
    // Unknown inputs makes an unknown result
    if( r0->singleton() ) {
!     intptr_t bits0 = r0->get_con();
      if( r1->singleton() ) 
        return bits0 == r1->get_con() ? TypeInt::CC_EQ : TypeInt::CC_GT;
      return ( r1->_ptr == TypePtr::NotNull && bits0==0 ) ? TypeInt::CC_GT : TypeInt::CC;
    } else if( r1->singleton() ) {
!     intptr_t bits1 = r1->get_con();
      return ( r0->_ptr == TypePtr::NotNull && bits1==0 ) ? TypeInt::CC_GT : TypeInt::CC;
    } else 
      return TypeInt::CC;
                                     
2004-06-11
EVALUATION

This bug reproduces only with "-server -d64" on 1.4.1_xx, 1.4.2_xx, 1.5.0-beta-b30. If I exclude "WhileLoopTest.<init>" method in .hotspot_compiler then problem never reproduces and the same has been confirmed from customer.

One more observation is, if I compile testcase src files with "1.4.1 javac" compiler and run with 1.4.1_xx(06, 07), 1.4.2_xx (03,04), 1.5.0-beta-b30 JVMs  then problem ALWAYS REPRODUCES. 
However, If I compile testcase src files with "1.4.2 javac" compiler and run with 1.4.2_xx (03,04), 1.5.0-beta-b30 JVMs then problem NEVER REPRODUCES. But it does REPRODUCE with 1.4.1_xx (07, 06) JVM.
It seems for customer it is not possible to compile their application with 1.4.2 javac compiler and then run. We need to address this with 1.4.1, 1.4.2, 1.5 JVMs  since there could be pre-compiled classes with 1.4.1 javac compiler and run with any of these JVMs. 
                                     
2004-06-11
WORK AROUND

Use:
1) s.equals("") instead of s=="", 
2) s.length()==0 instead of s=="", 
3) only -server compiler without -d64. 
4) exclude method from compilation in .hotspot_compiler as
   exclude WhileLoopTest <init> 
                                     
2004-06-11



Hardware and Software, Engineered to Work Together