|
Quick Lists
|
|
Bug ID:
|
6636138
|
|
Votes
|
0
|
|
Synopsis
|
UseSuperWord enabled failure
|
|
Category
|
hotspot:compiler2
|
|
Reported Against
|
|
|
Release Fixed
|
hs15(b05),
7(b54) (Bug ID:2175661)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
2-High
|
|
Related Bugs
|
6812207
,
6837906
|
|
Submit Date
|
30-NOV-2007
|
|
Description
|
Licensee has reported the following, during efforts to port their current VM to Java 6.
From Licensee:
During our efforts to port our current XXXJVM to Java 6. During the execution of this
task, I have come across a problem connected with the UseSuperWord option. I noticed
that this option is disabled by default in the latest version, namely 4 b06.
Nevertheless, I wanted to draw your attention to the enclosed test case. The program
runs forever, thus the method initialize_int_arraycopy will occasionally get compiled.
Execution of the compiled code fails on a super word enabled VM. The erronous code
performs an incorrect value copy, which is later discovered in the method
checkandfail_int_arraycopy. However, the test case is correctly executed if the
UseSuperWord option is deactivated. See attached testcase, (arraycopytest.java)
Posted Date : 2007-11-30 23:28:26.0
|
|
Work Around
|
N/A
|
|
Evaluation
|
This appears to be a previously unreported problem since it happens in 1.7 as well. It looks like the memory graph surgery that's performed to group the vectorizable memory operations is losing a couple of the stores in the slices that weren't vectorized.
Posted Date : 2007-12-03 21:44:09.0
Yes, it is the memory graph surgery problem. When we group a set of vectorized instruction together, we have to move the sandwitched instructions outside
the group, meaning we have to adjust the memory input/output. This memory graph surgery should be performed based upon data dependence analysis.
I have developed a new superword scheduling algorithm to handle this.
Posted Date : 2009-03-12 17:26:05.0
Here is the problem loop (in arraycopytest.initialize_int_arraycopy)
// initialize the arrays
for (int i = 0; i < src.length; i++) {
src[i] = ((i & 0x7fffffff));
dst[i] = ((src[i]) | 0x80000000);
srcrefconjoint[i] = src[i];
}
After unrolling, part of the loop looks like:
src[i] = ((i & 0x7fffffff));
dst[i] = ((src[i]) | 0x80000000);
srcrefconjoint[i] = src[i]; // (1)
src[i+1] = (((i+1) & 0x7fffffff));
dst[i+1] = ((src[i+1]) | 0x80000000);
srcrefconjoint[i+1] = src[i+1]; // (2)
The load src[i] and src[i+1] in statements (1) and (2). respectively, can be packed together.
In packing them into superword, their memory input should be the same (store). The original
memory surgery wrongly used dst[i] as their memory input. This essentially violate the data
dependence from the store src[i+1] to the load src[i+1] in statement (2). In this case, it
is safe to use dst[i+1] as their memory state input.
Posted Date : 2009-03-12 18:02:56.0
http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/78af5ae8e731
Posted Date : 2009-03-24 21:54:55.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |