JDK-6686791 : Side effect in NumberFormat tests with -server -Xcomp (all platforms, 6u5 perf release b01)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs12,6u10
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.5.1
  • CPU: generic,sparc
  • Submitted: 2008-04-10
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
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 6 JDK 7 Other
6u14Fixed 7Fixed hs12Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
JCK: JCK-runtime-6a alt. bundle
J2SE: FAIL - 6u5p b01, PASS 6u5,  6u4p
Platform[s]: FAIL -  All
switch/Mode: FAIL - -server -Xcomp

Test api/java/text/NumberFormat/Format has side effect since 6u5p b01. For example:

java -server -Xcomp -Xfuture -classpath K:\\Links\\stt\\jck_promotions\\6a\\fcs\\alt2\\binaries\\JCK-runtime-6a\\classes javasoft.sqe.tests.api.java.text.NumberFormat.FormatTests -TestCaseID NumberFormat0010

test reports:
NumberFormat0006: Passed. OKAY

passes. At the sampe time when run after another test it fails:
java -server -Xcomp -Xfuture -classpath K:\\Links\\stt\\jck_promotions\\6a\\fcs\\alt2\\binaries\\JCK-runtime-6a\\classes javasoft.sqe.tests.api.java.text.NumberFormat.FormatTests -TestCaseID NumberFormat0006 NumberFormat0010
NumberFormat0006: Passed. OKAY
NumberFormat0010: Failed. Failed
Method format(Object, StringBuffer, FieldPosition) incorrect
StringBuffer passed to format(Long, StringBuffer, FieldPosition) method
  expected value of StringBuffer =
  passed value  =
STATUS:Failed.test cases: 2; passed: 1; failed: 1; first test case failure: NumberFormat0010

Test does nothing except assigning one StringBuffer instance to a member of class NumberFormatTest then comparing both objects with ==. 

Steps to reproduce:
run commands above. 
Unix path to JCK is:

test sources:

EVALUATION New optimization in CmpPNode::sub() (6667580) removed the valid compare instruction because of false positive report from detect_dominating_control() since one of the input (LoadP) has a control edge above the allocation (second input to CmpP node). Class A { B fb; foo(B b) { fb = b; } } int bar() { A a = new A(); // Here a_init is Initialize(a)->proj#0 B b = new B() a.foo(b); // Not Inlined. if (b != a.fb) { // <<< this check is eliminated since LoadP->in(0) == a_init // and detect_dominating_control() return true. // LoadP->in(0) is set in MemNode::Ideal_DU_PostCPP(). return 1; } return 0; }