harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Egor Pasko (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-1682) Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
Date Wed, 04 Oct 2006 07:53:21 GMT
Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
--------------------------------------------------------------------------------

                 Key: HARMONY-1682
                 URL: http://issues.apache.org/jira/browse/HARMONY-1682
             Project: Harmony
          Issue Type: Bug
          Components: DRLVM
         Environment: Linux/IA32
            Reporter: Egor Pasko
            Priority: Critical
         Attachments: ClTest.java

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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message