harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-1682) Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
Date Tue, 10 Oct 2006 09:18:21 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-1682?page=comments#action_12441105 ] 
            
Ivan Volosyuk commented on HARMONY-1682:
----------------------------------------

Note for commiters. The only patch to be applied is:  jit_gc.diff

> 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
>         Assigned To: weldon washburn
>            Priority: Critical
>         Attachments: ClTest.java, interior_assert.diff, jit_gc.diff, retrieve_root_set.diff
>
>
> 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