harmony-commits mailing list archives

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

I'm agree that GC should not move objects during the enumeration.
The example: if JIT has 2 references to the same object JIT will report both of them and expect
GC updates both references. But if the object is moved after it's reported the first time,
the second report to the old memory location will fail.

> 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
>
>
> 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