Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 93583 invoked from network); 9 Nov 2006 15:21:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Nov 2006 15:21:27 -0000 Received: (qmail 21804 invoked by uid 500); 9 Nov 2006 15:21:35 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 21760 invoked by uid 500); 9 Nov 2006 15:21:34 -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 21751 invoked by uid 99); 9 Nov 2006 15:21:34 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Nov 2006 07:21:34 -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 alexey.v.varlamov@gmail.com designates 66.249.82.233 as permitted sender) Received: from [66.249.82.233] (HELO wx-out-0506.google.com) (66.249.82.233) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Nov 2006 07:21:20 -0800 Received: by wx-out-0506.google.com with SMTP id h29so214472wxd for ; Thu, 09 Nov 2006 07:21:00 -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=Oti0+JOo3wSZJpgwMuJoPjqjUPu1ApAYAPHHoeeZ0MiqLzIGnoUSR71yFeBOD8d8JItFr/a04yCSZloUKVRe/SLA1feSRiyUiLiDxhOW4rPNgVTaR6gAbuXkmO7HLYmcpG5gHcj/uh6d7MrcsyEWu9IvbmVnXvSrYJSojO0tjVU= Received: by 10.70.8.8 with SMTP id 8mr911068wxh.1163085659925; Thu, 09 Nov 2006 07:20:59 -0800 (PST) Received: by 10.70.50.2 with HTTP; Thu, 9 Nov 2006 07:20:59 -0800 (PST) Message-ID: Date: Thu, 9 Nov 2006 21:20:59 +0600 From: "Alexey Varlamov" To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] Class unloading support - tested one approach In-Reply-To: <455324E1.2040301@anu.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com> <4551B15B.2070101@anu.edu.au> <5836de490611080250l6dfbd38cw8778f7a055373d82@mail.gmail.com> <4551B83D.9020706@anu.edu.au> <4551CBDB.90004@anu.edu.au> <45531ED7.7030904@sablevm.org> <455324E1.2040301@anu.edu.au> X-Virus-Checked: Checked by ClamAV on apache.org 2006/11/9, Robin Garner : > Etienne Gagnon wrote: > > Alexey Varlamov wrote: > >> Sorry if it was already discussed, but I believe this approach also > >> requires marking vtable bit/byte on each object allocation, unitl the > >> "unloading" GC pass is strictly stop-the-world full-heap collection. > >> Robin, did you include this particular overhead too in your > >> measurements? > > I didn't include it - having established that it's cheap during GC where > memory bandwidth is at a premium, I kind of took this for granted. > > > My proposal already argued that vtable bit/byte/word marking is > > unnecessary for "nursery allocations". You only need to mark the vtable > > of objects that survive collection and pretenured objects. I may have missed it, but I only recall you argued that we just need to collect mature space for the *final unloading* as CL and classes are unlikely to die young, which I agree. But chances that a live object of a candidate class appeared in the nursery are higher. Otherwise I just do not grok how this algorithm can be proven for correctness. > And this is a persuasive argument. But I can probably find time to > measure it tomorrow if you aren't convinced. That would be very kindly, thank you. -- Alexey > > -- > Robin Garner > Dept. of Computer Science > Australian National University >