Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 63783 invoked from network); 27 Oct 2006 14:43:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Oct 2006 14:43:10 -0000 Received: (qmail 23649 invoked by uid 500); 27 Oct 2006 14:43:18 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 23604 invoked by uid 500); 27 Oct 2006 14:43:18 -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 23595 invoked by uid 99); 27 Oct 2006 14:43:18 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Oct 2006 07:43:18 -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 (herse.apache.org: domain of pmcfirst@gmail.com designates 64.233.162.196 as permitted sender) Received: from [64.233.162.196] (HELO nz-out-0102.google.com) (64.233.162.196) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Oct 2006 07:43:01 -0700 Received: by nz-out-0102.google.com with SMTP id z3so553787nzf for ; Fri, 27 Oct 2006 07:42:39 -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=MiengK7RTQVYyYV38Dk/B3BCbL9YYbRfOVx9FAagNf1Bef2txc4LjpWUZyfeHIyB8Xqnqe2x8q8CtlcdQM2tFjzWHYYqKDY042+M8lypyvoeKLsBOVjKE7xMNLzz+7DF4x9NOvhPriz0gmRCyqRy9AZW9XOTSNkCd8qfYfE3d6Q= Received: by 10.35.82.16 with SMTP id j16mr280249pyl; Fri, 27 Oct 2006 07:42:37 -0700 (PDT) Received: by 10.35.9.7 with HTTP; Fri, 27 Oct 2006 07:42:36 -0700 (PDT) Message-ID: Date: Fri, 27 Oct 2006 18:42:36 +0400 From: "Pavel Pervov" To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] Class unloading support In-Reply-To: <4dd1f3f00610262141j4f576ffdgeed5e9a268ddefe7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_109736_8857798.1161960156896" References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com> <5836de490610242132s61fc1eb4n9eff2bdb1f45f2f1@mail.gmail.com> <51d555c70610261450w27b9e7a0y981bb1468201153e@mail.gmail.com> <4dd1f3f00610262141j4f576ffdgeed5e9a268ddefe7@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_109736_8857798.1161960156896 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think I know where the idea of additional reference to j/l/Class in every object came from. Lets look at original proposal: "... *Automatic class unloading approach.* ... To do that we need to provide two conditions: 1. Introduce reference from object to its j.l.Class instance. ..." Lets rephrase the latter the following way: "1. Make j.l.Class reachable from all objects of that class." As everybody agrees that adding one more pointer into object overhead is not a good idea, the only way is making j.l.Class reachable through available data - in other words through VTable, which becomes regular Java object. That is it. Resume: no direct reference to j.l.Class in object of that class, no additional object overhead, no MMTk incompatibility. On 10/27/06, Weldon Washburn wrote: > > Steve Blackburn was in Portland Oregon today. I mentioned the idea of > adding a reference pointer from object to its j.l.Class instance. MMTk > was > not designed with this idea in mind. It looks like you will need to fix > this part of MMTk and maintain it yourself. Steve did not seem thrilled > at > adding this support to MMTk code base. -- Pavel Pervov, Intel Enterprise Solutions Software Division ------=_Part_109736_8857798.1161960156896--