Bug ID: JDK-6686791 Side effect in NumberFormat tests with -server -Xcomp (all platforms, 6u5 perf release b01)

Versions (Unresolved/Resolved/Fixed)

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

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:

/net/stt-13.russia.sun.com/export/stt/jck_promotions/6a/fcs/alt2/binaries/JCK-runtime-6a/classes
test sources:
/net/stt-13.russia.sun.com/export/stt/jck_promotions/6a/fcs/alt2/binaries/JCK-runtime-6a/tests

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; }

11-04-2008

Duplicate :	JDK-6782006 - Reading InputStream of large amount of data results in corrupted data
Relates :	JDK-6701887 - JDK7 server VM in endless loop between Node::dominates and Node::find_exact_control
Relates :	JDK-6667580 - Optimize CmpP for allocations
Relates :	JDK-6692301 - Side effect in NumberFormat tests with -server -Xcomp (all platforms, 6u5 perf release b01)