Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 88032 invoked from network); 17 Oct 2006 05:31:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Oct 2006 05:31:24 -0000 Received: (qmail 58655 invoked by uid 500); 17 Oct 2006 05:31:22 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 58251 invoked by uid 500); 17 Oct 2006 05:31:21 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 58240 invoked by uid 99); 17 Oct 2006 05:31:21 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Oct 2006 22:31:21 -0700 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of rdasgupt@gmail.com designates 64.233.162.195 as permitted sender) Received: from [64.233.162.195] (HELO nz-out-0102.google.com) (64.233.162.195) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Oct 2006 22:31:20 -0700 Received: by nz-out-0102.google.com with SMTP id z6so625360nzd for ; Mon, 16 Oct 2006 22:31:00 -0700 (PDT) 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:references; b=Az2ZVQOAMPEReeGyOtExn+841o4nbtYYK2/HBjwj7xiqmfPtsnEMyTeofhjEJRt/X/w+XVmWRtgX6sJAVWc8UfuVKseShlVBextvx051iq73gDFKnf2xDcn5vAFRBXgEzN/hYUxMTR/yfXZp7PQuWDCmS5b2n8dWtjZ5vvLrHcM= Received: by 10.64.241.3 with SMTP id o3mr11460826qbh; Mon, 16 Oct 2006 22:31:00 -0700 (PDT) Received: by 10.65.203.19 with HTTP; Mon, 16 Oct 2006 22:31:00 -0700 (PDT) Message-ID: <51d555c70610162231x325acecbxdfa23fcdc30e7bae@mail.gmail.com> Date: Mon, 16 Oct 2006 22:31:00 -0700 From: "Rana Dasgupta" To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc In-Reply-To: <453314B6.8050903@anu.edu.au> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_46693_13970172.1161063060133" References: <9623c9a50610112041t5e1851cek96c15b133d723140@mail.gmail.com> <9623c9a50610122009n7f1eba4cpfe7f40a3cd83a7ef@mail.gmail.com> <51d555c70610130055v6a8cd57eq995763a1f0b3cefa@mail.gmail.com> <452F5BA2.2080706@anu.edu.au> <4dd1f3f00610130742g59079c1ek5d22c108c1376496@mail.gmail.com> <453314B6.8050903@anu.edu.au> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_46693_13970172.1161063060133 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Robin, I found your last set of comments very illuminating. Thanks. On your suggestion below...who would manage this object, ie., construct and populate it, etc. before invoking the helper instance method? The jit? I think that some of the VM specific information has started leaking into the jit already! What if we want to attach a new JIT into Harmony/DRLVM ...what would be the requirements for such a jit? Regarding the terse Java in the fastpath code, what one can do in the fastpaths is somewhat constrained, isn't it? They are mostly uninterruptible, shouldn't raise exceptions, cause gc etc. Our java layer in the infrastructure is somewhat localized. Thanks, Rana > On 10/15/06, Robin Garner wrote: > > > > Weldon Washburn wrote: > > > Robin, > > > I really like your thinking! I would like to see Harmony drlvm > > support > > > MMTk > > > fully. this may take a while. Please feel free to keep pushing to do > > the > > > right thing with the JIT. > > > > Well, with this encouragement, there are a few more things I'd like to > > suggest: > > > > - Rather than make TLS access be a magic, how about defining an object > > with fields that point to all the VM resources (such as TLS) that a > > helper wants, and then calling the helper as an instance method of that > > object ? > > > > . If devirtualisation of this is problematic for the JIT at the > > moment, perhaps introduce a magic pragma instead of the TLS access > > handler > > > > - Mikhail's prototype Java helper looks like C transliterated into Java. > > This is reminiscent of the very early days of JikesRVM. IMO, you > > should actually use Java here rather than fight it ... define an > > abstract Allocator class, and a concrete BumpPointer instance for > > example. > > > > One of the lessons of MMTk was how much you can trust the compiler, and > > each revision uses more and more object orientation. You guys are in an > > ideal position, because you have control over the compiler as well as > > the java code. > > > > cheers > > > > ------=_Part_46693_13970172.1161063060133--