From harmony-dev-return-8219-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Mon Jun 05 19:04:33 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 80094 invoked from network); 5 Jun 2006 19:04:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Jun 2006 19:04:32 -0000 Received: (qmail 16165 invoked by uid 500); 5 Jun 2006 19:04:26 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 16111 invoked by uid 500); 5 Jun 2006 19:04:25 -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 16100 invoked by uid 99); 5 Jun 2006 19:04:25 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Jun 2006 12:04:25 -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 weldonwjw@gmail.com designates 66.249.92.169 as permitted sender) Received: from [66.249.92.169] (HELO ug-out-1314.google.com) (66.249.92.169) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Jun 2006 12:04:25 -0700 Received: by ug-out-1314.google.com with SMTP id q2so1500729uge for ; Mon, 05 Jun 2006 12:04:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NX7cCOe34Mm7fMqDoFmVC8YtgvrUKTTsPMlIoWCIEelry0KZ8VBwd0krfObMhscTeAEsgXujQWjvrfyoYyuZrh0ANfzn59Ap999MkoSyyFT1rQ8J3+apXwyxFBjFwW1Xh6S4Edd9sGc4I/RTmhkAxBQLGfVup6cQxOF7xb9fta8= Received: by 10.78.52.17 with SMTP id z17mr956952huz; Mon, 05 Jun 2006 12:04:03 -0700 (PDT) Received: by 10.78.72.15 with HTTP; Mon, 5 Jun 2006 12:04:03 -0700 (PDT) Message-ID: <4dd1f3f00606051204j60359281me03f879d8f040bff@mail.gmail.com> Date: Mon, 5 Jun 2006 12:04:03 -0700 From: "Weldon Washburn" To: harmony-dev@incubator.apache.org Subject: [DRLVM] MMTk write barrier -- questions about which writeBarrier() API to use MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N All, Perhas the MMTk crowd knows the answer to the following questions. Can I simply not use org.mmtk.plan.PlanLocal.writeBarrier(ObjectReference src, Address slot, ObjectReference tgt, Offset metaDataA, int metaDataB, int mode);? Instead, I want to only use writeBarrier(ObjectReference src, Offset srcOffset, ObjectReference dst, Offset dstOffset, int bytes);. Will this be a problem? Questions about the incoming args: ObjectReference src >From the JITs perspective, an ObjectReference is indistinguishable from a java.lang.Object. Is this true? False? Address slot When is "Address slot" argument actually created? Does this Address object live long enough such that its "value" field needs to be updated following a copying GC? Is the answer the same for both Jikes and the Rotor ports? Offset srcOffset In DRLVM, the classloader resolves a field offset once and it never changes. Does it make sense for the classloader to create all the Offset objects during load time? Initially, I want to create these objects _outside_ the formal java heap to have tight control over object movement and deletion. Basically, I don't want the Offset object to ever move or ever be deleted during the initial stages of MMTk integration. A question about how jikesrvm-2.4.4/MMTk handles objects that are not inside the offical heap. Are these objects simply ignored? I know that ECMA CLI spec requires that objects which are not in the official heap must be ignored. I simply don't know if this requirement is incorporated in 2.4.4/MMTk source base. While it looks like a lot of work to get DRLVM to generate Offset object properly, it looks like even a bigger job to modify MMTk to replace Offset class with an "int" that holds a given field's offset. Any opinions on this statement? -- Weldon Washburn Intel Middleware Products Division --------------------------------------------------------------------- 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