From dev-return-30393-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Tue Nov 06 09:05:14 2007 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 22583 invoked from network); 6 Nov 2007 09:05:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Nov 2007 09:05:14 -0000 Received: (qmail 13629 invoked by uid 500); 6 Nov 2007 09:04:40 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 13609 invoked by uid 500); 6 Nov 2007 09:04:40 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 13595 invoked by uid 99); 6 Nov 2007 09:04:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2007 01:04:40 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mloenko@gmail.com designates 64.233.182.186 as permitted sender) Received: from [64.233.182.186] (HELO nf-out-0910.google.com) (64.233.182.186) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2007 09:04:42 +0000 Received: by nf-out-0910.google.com with SMTP id k4so1552227nfd for ; Tue, 06 Nov 2007 01:04:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hkXAfDYAP/1WdUfA+X8LD2tD0LYlOmLYDgP8hPe7FYQ=; b=fXrrqSDFrrwldStJ56yR523MdH/w50NaFGmqAXcrVh2SpjKIO562A8TKImD19biWmTbbxzye1qNmt8RParjP+0d10bmBA1+LtbuvZTDFP0rhiisg3QYjXJ5CjY3Jxf7PMdfsdzNkI7UjMib9341CzfjEACnoXr3tNkkFPXaTyEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rDv8HNiccUuUfnaC6DJhpqFhLrlmFwBuOn0AizHG54BoE4i6PAb2oe7W5XB/xmuWbHHnL3koWgekloQFmM4yFv3N5l5cXDbi1Xlfuwp9ATsuWQOjHLSJqkcCwgOHoKgr3/k7QBhYgbesTrb19JWZXKen7NYjvWADXC7HGoTw3y4= Received: by 10.78.171.20 with SMTP id t20mr4640086hue.1194339860452; Tue, 06 Nov 2007 01:04:20 -0800 (PST) Received: by 10.78.14.11 with HTTP; Tue, 6 Nov 2007 01:04:20 -0800 (PST) Message-ID: <906dd82e0711060104h2a9c82a0t4a3f10e624a21ce5@mail.gmail.com> Date: Tue, 6 Nov 2007 15:04:20 +0600 From: "Mikhail Loenko" To: dev@harmony.apache.org Subject: Re: [drlvm][verifier] Dead-code and Java 6 verification issues In-Reply-To: <54453.82700.qm@web55211.mail.re4.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <54453.82700.qm@web55211.mail.re4.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org Hi Asaf, thanks for separating this discussion into a different thread! 2007/11/6, Asaf Yaffe : > Hi, > > This mail thread is for discussing Java 6 verification issues related to dead-code. The issue was first brought up by Mikhail Loenko in the "[drlvm][verifier] Using the Harmony verifier code for computing the StackMapTable attribute" mail thread. > > Here's a general overview of this subject for anyone who wishes to join this discussion: the Java 6 verifier requires the presence of StackMap data at the beginning of each basic block. This requirements is true for all types of blocks, including "dead-blocks" (i.e., blocks unreachable from the first block in a method's control-flow graph). The problem is that StackMaps are computed using a control-flow/data-flow algorithm which (by definition) processes only reachable blocks, and hence cannot be used on "dead" blocks. In short - StackMaps cannot be computed for "dead" blocks. > > So, the main question is this: what do we do with dead blocks? How do we compute their StackMaps? > > One possible option is to remove the dead-code from the method by means of a dead-code removal algorithm applied to the method byte codes. Another possible option (implemented by the ASM BCI library) is to "nop" all instructions in the dead block up to the last one, modify the last instruction to "athrow" and assigning a StackMap of [][java/lang/Throwable] to this block [1]. > > Any other thoughts, suggestions or ideas? As I understand, there are three options possible: 1) remove the dead code, 2) provide valid stackmaps for it, and 3) simplify the code and provide stackmaps for the simplified code I like the idea of simplification which you pointed, but I think this approach is not quite correct in general: the dead code might be in the try block. In this case stackmap locals at the dead block should be assignable to stackmap at the handler_pc instruction. In other words, if catch block accesses locals defined before the try block and this try block has a dead code, then stackmap for the dead code can't have empty locals: otherwise Java6 verification would fail I suggest that we take locals from the stackmap of the first instruction after the dead code. And we modify try blocks that have dead code in the beginning or in the end so that dead code is excluded from try blocks (unless it's in the middle) Thanks, Mikhail > > Thanks, > Asaf > > [1] ASM developer guide: http://asm.objectweb.org/doc/developer-guide.html#deadcode > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com