harmony-commits mailing list archives

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

Mikhail said:
> If JIT has multiple mptrs for the same base to report, will this base relocated when
mptr is reported? 

The short answer is, I think it best that the GC does not move anything during enumeration.
 The JIT should plan on this for the foreseeable future.

Maybe much later on we will need move objects and update stack/register locations while enumeration
unwind is under way.  This might be needed for multicore hardware.  And an excellent approach
would be analyze relevant workloads on real multicore HW using existing (boring) enumeration
protocol.  Once hot spots are identified, we can discuss changes to the existing JIT/GC interface.
  But for now, let's learn to crawl before learning to walk.

> 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