Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
None
-
None
-
None
-
Linux/IA32
-
Moderate
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"))
}
}
"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.