[HARMONY-1682] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Component/s: DRLVM
• Environment: Linux/IA32
• Estimated Complexity: Moderate
• Assignee: Geir Magnusson Jr
• Reporter: Egor Pasko
• Created: 04/Oct/06 07:51
• Updated: 14/Oct/06 15:22
• Resolved: 14/Oct/06 15:22

Description

the problem in brief:
(see more details in the attached test)
for (int i = 0; i < N; i++) {
something = A[i].Something();
for (int j = 0; j < A[i].getArray().length; j++) {
// perform some GC intensive action here
if (A[i].getArray()[j].getName().equals("xxx"))

{ // use A[i] here break; }

}
}

"memopt" optimization pass eliminates the innermost memory read accesses to A[i] preserving a temporary reference to the object in the innermost loop. When a GC intensive action is performed, the array (A) is moved to another location, but the temporary reference is not updated with GC (which leads to crash). So, I suspect a problem in GC enumeration or, maybe, some other aspects of JIT<->GC interface.

some facts:
On Jitrino.JET the test passes.
On Jitrino.OPT the test leads to crash:
$ $JAVA -Xem:opt ClTest
SIGSEGV in VM code.
Stack trace:
1: ?? (??:-1)
<end of stack trace>
Segmentation fault
If "memopt" is turned OFF in opt.emconf, the test passes on Jitrino.OPT (but memopt performs correct transformations, which is visible from log files)
If a larger Java heap is specified (which postpones GC actions), the test takes longer to run, but crashes, anyway:
$ $JAVA -Xms1024m -Xmx1024m -Xem:opt ClTest
1_20
2_20
3_20
4_20
5_20
6_20
7_20
8_20
9_20
SIGSEGV in VM code.
Stack trace:
1: ?? (??:-1)
<end of stack trace>
Segmentation fault

The test is reduced from the kernel test ClassLoaderTest which fails with exactly the same symptoms.