[jira] Updated: (HARMONY-1682) Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses

["Egor Pasko (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/HARMONY-1682?page=all ]

Egor Pasko updated HARMONY-1682:
--------------------------------

    Attachment: ClTest.java

the test to reproduce
crashes on the latest DRLVM with -Xem:opt

> 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