Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 68327 invoked from network); 5 Dec 2006 00:15:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Dec 2006 00:15:59 -0000 Received: (qmail 91304 invoked by uid 500); 5 Dec 2006 00:16:06 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 91278 invoked by uid 500); 5 Dec 2006 00:16:06 -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 91268 invoked by uid 99); 5 Dec 2006 00:16:06 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Dec 2006 16:16:06 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com designates 66.249.92.172 as permitted sender) Received: from [66.249.92.172] (HELO ug-out-1314.google.com) (66.249.92.172) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Dec 2006 16:15:55 -0800 Received: by ug-out-1314.google.com with SMTP id z36so2523976uge for ; Mon, 04 Dec 2006 16:15:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=diPlrh6ZZxn9WM0o5boPexCH0UHxRnKEAbDKVQdVNDP1U+tkN2eZ0kEosHAD4oq97f/9Uqe+0QfsNJ340Cn4yDsPEPq42VFaXrezttCbO1nSlPVgUBNBFw17z0T0VHC6ZUv/QjTfPV1DEl9DNk0laLtUb5iB7QON5EvbmpUxTe8= Received: by 10.78.164.13 with SMTP id m13mr8262789hue.1165277733346; Mon, 04 Dec 2006 16:15:33 -0800 (PST) Received: by 10.78.154.18 with HTTP; Mon, 4 Dec 2006 16:15:33 -0800 (PST) Message-ID: <9623c9a50612041615y2da4fa33t69189ea15a9b1309@mail.gmail.com> Date: Tue, 5 Dec 2006 08:15:33 +0800 From: "Xiao-Feng Li" To: dev@harmony.apache.org Subject: Re: [drlvm][gcv5] is there an exclude list for "build test"? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4dd1f3f00611301156s6dc93104mfef55c4b862b2f42@mail.gmail.com> <12385bbd0611301545i2b518e6ehce280853686e6c2c@mail.gmail.com> <9623c9a50611301632j4ba8d007v97c9887bd1e45d65@mail.gmail.com> <9623c9a50612012145j44b3f708uf148d3760fab109c@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org On 12/4/06, Mikhail Fursov wrote: > On 12/2/06, Xiao-Feng Li wrote: > > > > > > At the same time, I wonder if that's better for JIT to check the > > finalizable property for VM helper as well. I guess this can be easier > > for VM helpers since they are GC independent with standard interface. > > Only guess anyway, how do you think, Mikhail? > > > > It's not a problem to check "isFinalizable" for JIT during the compilation. > The question is how to use this knowledge. > Today JIT has only 1 usage scenario: do not inline fast-path helper for > objects with 'finalize' method. > If JIT checks this property before generating a call to usual VM method what > is the option? Should JIT call different VM helper for allocation in this > case? Mikhail, yes. I think you make the right point. My opinion is, JIT can call different native alocation function (alloc_fast or common alloc) as well as it does for helper inlining after it checks the finalization property. Actually in my experiments, I found the NEXT_TO_HIGH_BIT is no longer marked by JIT before its invocation to native GC alloc functions. That means, it is unused in current DRLVM. (That also means, the test case should be removed). So if without JIT's help, we need check gc_vtable for the finalization property even in the alloc_fast function (the native one). Thanks, xiaofeng > -- > Mikhail Fursov > >