Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <12448280.1172520367539.JavaMail.jira@brutus>
Date: Mon, 26 Feb 2007 12:06:07 -0800 (PST)
From: "Naveen Neelakantam (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (HARMONY-3242) [drlvm][jit] interface
 devirtualization bug
In-Reply-To: <25074699.1172520367406.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HARMONY-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Naveen Neelakantam updated HARMONY-3242:
----------------------------------------

    Attachment: devirt_bug.emconf

> [drlvm][jit] interface devirtualization bug
> -------------------------------------------
>
>                 Key: HARMONY-3242
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3242
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: RHEL4, gcc 4.1.0, core2
>            Reporter: Naveen Neelakantam
>         Attachments: devirt_bug.emconf, devirt_intf_bug.patch
>
>
> When devirtualizing an interface call, the devirtualizer incorrectly moves the ldInterfaceVTable instruction to immediately before function pointer calculation for each guarded virtual call.  This is problematic because a single ldInterfaceVTable instruction may be a producer for several function pointer calculations.  Moving the ldInterfaceVTable instruction can therefore prevent it from dominating its consumers.
> This bug will not manifest itself in most situations because global code motion (gcm) is typically run after interface devirtualization.  Global code motion will move the ldInterfaceVTable back into a basic block that dominates all of its consumers.
> So, to observe the bug a new .emconf is needed, one that does not run gcm.  I've attached devirt_bug.emconf which is a copy of server.emconf but with gcm removed.
> I've also attached a patch which fixes the issue (devirt_intf_bug.patch).  Instead of moving the ldInterfaceVTable instruction, the patch places a duplicate before each guarded function pointer calculation.
> Demonstration of bug using devirt_bug.emconf and the DaCapo chart benchmark:
> >java -showversion -Xem:./devirt_bug.emconf -jar dacapo-2006-10-MR2.jar chart
> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable.
> java version "1.5.0"
> pre-alpha : not complete or compatible
> svn = r511936, (Feb 26 2007), Linux/ia32/gcc 4.1.0, release build
> http://incubator.apache.org/harmony
> ===== DaCapo chart starting =====
> Done plotting: ./scratch/javac-tgt-ptr-prf-time.pdf
> Done plotting: ./scratch/javac-src-ptr-prf-time.pdf
> SIGSEGV in VM code.
> Stack trace:
> Done plotting: ./scratch/javac-dst-ptr-prf-time.pdf
> Done plotting: ./scratch/javac-tgt-mut-prf-time.pdf
> Done plotting: ./scratch/javac-src-mut-prf-time.pdf
>         1: ?? (:-1)
> read() failed during execution of addr2line
>         2: ?? (??:-1)
> read() failed during execution of addr2line
>         3: ?? (??:-1)
> read() failed during execution of addr2line
>         4: ?? (??:-1)
> read() failed during execution of addr2line
>         5: ?? (??:-1)
> read() failed during execution of addr2line
>         6: ?? (??:-1)
> read() failed during execution of addr2line
>         7: ?? (??:-1)
> read() failed during execution of addr2line
>         8: ?? (??:-1)
> read() failed during execution of addr2line
>         9: ?? (??:-1)
> read() failed during execution of addr2line
>         10: ?? (??:-1)
> read() failed during execution of addr2line
>         11: ?? (??:-1)
> read() failed during execution of addr2line
>         12: ?? (??:-1)
> read() failed during execution of addr2line
>         13: ?? (??:-1)
> read() failed during execution of addr2line
>         14: ?? (??:-1)
> read() failed during execution of addr2line
>         15: ?? (??:-1)
> read() failed during execution of addr2line
>         16: ?? (??:-1)
> read() failed during execution of addr2line
>         17: ?? (??:-1)
> read() failed during execution of addr2line
>         18: ?? (??:-1)
> read() failed during execution of addr2line
>         19: ?? (??:-1)
> read() failed during execution of addr2line
>         20: ?? (??:-1)
> read() failed during execution of addr2line
>         21: ?? (??:-1)
> read() failed during execution of addr2line
>         22: ?? (??:-1)
> read() failed during execution of addr2line
>         23: ?? (??:-1)
>         24: IP is 0xA50AADC3 <native code>
>         25: java/lang/EMThreadSupport.run()V (EMThreadSupport.java:68)
>         26: java/lang/EMThreadSupport$1.run()V (EMThreadSupport.java:44)
>         27: java/lang/Thread.run()V (Thread.java:-1)
>         28: java/lang/Thread.runImpl()V (Thread.java:-1)
> read() failed during execution of addr2line
>         29: ?? (??:-1)
> read() failed during execution of addr2line
>         30: ?? (??:-1)
> read() failed during execution of addr2line
>         31: ?? (??:-1)
> read() failed during execution of addr2line
>         32: ?? (??:-1)
> read() failed during execution of addr2line
>         33: ?? (??:-1)
> read() failed during execution of addr2line
>         34: ?? (??:-1)
> read() failed during execution of addr2line
>         35: ?? (??:-1)
> read() failed during execution of addr2line
>         36: ?? (??:-1)
> read() failed during execution of addr2line
>         37: ?? (??:-1)
> read() failed during execution of addr2line
>         38: ?? (??:-1)
> read() failed during execution of addr2line
>         39: ?? (??:-1)
> <end of stack trace>
> Segmentation fault

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.