|
Quick Lists
|
|
Bug ID:
|
6686791
|
|
Votes
|
0
|
|
Synopsis
|
Side effect in NumberFormat tests with -server -Xcomp (all platforms, 6u5 perf release b01)
|
|
Category
|
hotspot:compiler2
|
|
Reported Against
|
b02
|
|
Release Fixed
|
hs12(b03),
hs13(b01) (Bug ID:2161489)
|
|
State
|
10-Fix Delivered,
Verified,
bug
|
|
Priority:
|
1-Very High
|
|
Related Bugs
|
6667580
,
6692301
,
6701887
|
|
Submit Date
|
10-APR-2008
|
|
Description
|
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
Posted Date : 2008-04-10 14:43:36.0
|
|
Work Around
|
N/A
|
|
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;
}
Posted Date : 2008-04-11 16:40:12.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |