Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 70356 invoked from network); 24 May 2006 20:14:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 May 2006 20:14:15 -0000 Received: (qmail 18288 invoked by uid 500); 24 May 2006 20:14:12 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 18240 invoked by uid 500); 24 May 2006 20:14:12 -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 18229 invoked by uid 99); 24 May 2006 20:14:12 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 May 2006 13:14:12 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of csdread@gmail.com designates 64.233.166.179 as permitted sender) Received: from [64.233.166.179] (HELO py-out-1112.google.com) (64.233.166.179) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 May 2006 13:14:11 -0700 Received: by py-out-1112.google.com with SMTP id c59so4842472pyc for ; Wed, 24 May 2006 13:13:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZK/OqlWIDd0VBt80cROp+aGylSHBONfWwB7kr8iKwpNFbq0iOwVZZnyhUAPV2O3ZDCG5k4kOH1t7y1lv88d+xnYaERdZ0e6AhLJYfk3W7m0s1Q1KyR1E16DFcU4f1yYr7JrUl7MpYsdWzap6I132Z5+8BixPUoIJsA5uf1DvVRU= Received: by 10.35.66.12 with SMTP id t12mr1103786pyk; Wed, 24 May 2006 13:13:50 -0700 (PDT) Received: by 10.35.10.4 with HTTP; Wed, 24 May 2006 13:13:50 -0700 (PDT) Message-ID: <1b3e8afb0605241313jabd3151h4ab1002e050dc42a@mail.gmail.com> Date: Wed, 24 May 2006 14:13:50 -0600 From: "Daniel Feinberg" Reply-To: danielf@cs.unm.edu To: harmony-dev@incubator.apache.org Subject: Fwd: [DRLVM] proposal to port MMTK to drlvm In-Reply-To: <1b3e8afb0605241313h5cf6b540o782bfaa621e53d47@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4dd1f3f00605232308k4f076eb4r8898cc920d77c6e3@mail.gmail.com> <51d555c70605240902i53d1044fnc5a355b4b5142223@mail.gmail.com> <4dd1f3f00605241129n3d20b80foe2bf2c2d0d32e4c7@mail.gmail.com> <1b3e8afb0605241244u3841e0a9r8ca6a1acc99334d@mail.gmail.com> <4dd1f3f00605241306u3ac53f90tc835305e22fb300c@mail.gmail.com> <1b3e8afb0605241313h5cf6b540o782bfaa621e53d47@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ---------- Forwarded message ---------- From: Daniel Feinberg Date: May 24, 2006 2:13 PM Subject: Re: [DRLVM] proposal to port MMTK to drlvm To: Weldon Washburn Something like a reference counter does not really need a write barrier. They are mostly used when you are partitioning the heap into specific regions for objects that fit cirtian specifications. And again only if you are going to be collecting a region that has pointers that flow into the collected section of the heap. There might be other uses of write barriers. Another kind of collector that might be of interest that i dont believe is included in MMTK though it should be is the Older First collector which you can get the paper at the DaCapo website. Daniel On 5/24/06, Weldon Washburn wrote: > On 5/24/06, Daniel Feinberg wrote: > > > >My understanding of write barriers is as an optimization. > > > That fits with my understanding of write barriers also. I do not > > > know for certain but suspect that MMTK can somehow be configured such > > > that write barriers are not required for correctness. Maybe Dan > > > Feinberg can tell the mailing list. > > > > So MMTK is a toolkit for building GCs. When doing generational > > collection the write barrier is used to keep track of pointers that go > > from older generations to yonger generations. You must have a way to > > track these objects because when you do a partial heap collection (aka > > just the nursery or nursery and old1) you need to build a root set of > > all things that point into that space. Then you trace this root set to > > find all live objects that need to be moved to an older generation. In > > other methods of collecting the write barrier is not as important. > > Thanks. This fits my expectations. One follow-up question. By "not > as important", do you mean functionally correct but bad performance or > something else? > > > > Here unless you can find all of these pointers that point into a space > > from an older space you must use a write barrier. > > > > > > > Daniel > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org > > > > > > > -- > Weldon Washburn > Intel Middleware Products Division > -- Daniel Feinberg http://www.cs.unm.edu/~danielf --=20 Daniel Feinberg http://www.cs.unm.edu/~danielf --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org For additional commands, e-mail: harmony-dev-help@incubator.apache.org