Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
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
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang