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 Wed, 04 Oct 2006 12:38:21 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-1682?page=comments#action_12439821 ] 
            
Mikhail Fursov commented on HARMONY-1682:
-----------------------------------------

Ivan, I checked the test you sent
The test fails and GC runs only once before the failure.
I moved all methods except the problem one to Jitrino.JET and Jitrino.OPT reports only 2 items:
one object and one [mptr, object] pair with a small offset.

According to the IR I have this is OK.
The GC enumeration point is:
I36: (AD:t54(EAX):cls:ClTest$Package[]) =CALL t53(-390:m:ClTest$MyObject.getPackages):int32
(AU:t43(EAX):cls:ClTest$MyObject) 

I can help you to add more logging into Jitrino.OPT GCMap algorithms. Can you imagine the
logging that will help?

> 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