Bug ID: JDK-6636138 UseSuperWord enabled failure

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
6u18Fixed	7Fixed	hs15Fixed

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)

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/78af5ae8e731
24-03-2009
EVALUATION 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.
12-03-2009
EVALUATION 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.
12-03-2009
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.
03-12-2007

Duplicate :	JDK-6812207 - Possible bug in a floating point (float) arithmetic in 32-bit server HotSpot
Relates :	JDK-6837906 - compiler tests of 6636138 fail with IllegalAccessException
Relates :	JDK-6877254 - Server vm crashes with "no branches off of store slice" when run with CMS and UseSuperWord (default)
Relates :	JDK-6876276 - assert(!is_visited,"visit only once")
Relates :	JDK-6816756 - Remove useless pre/post barriers when the corresponding store is optimized away