From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32369 invoked by alias); 17 May 2007 19:50:43 -0000 Received: (qmail 32360 invoked by uid 22791); 17 May 2007 19:50:42 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 May 2007 19:50:37 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l4HJnKUk001577; Thu, 17 May 2007 15:49:21 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4HJnJEX031839; Thu, 17 May 2007 15:49:19 -0400 Received: from free.oliva.athome.lsd.ic.unicamp.br (vpn-14-148.rdu.redhat.com [10.11.14.148]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4HJnGLV022504; Thu, 17 May 2007 15:49:17 -0400 Received: from free.oliva.athome.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.oliva.athome.lsd.ic.unicamp.br (8.14.1/8.13.8) with ESMTP id l4HJnDb5022335; Thu, 17 May 2007 16:49:13 -0300 Received: (from aoliva@localhost) by free.oliva.athome.lsd.ic.unicamp.br (8.14.1/8.13.5/Submit) id l4HJnB7k022333; Thu, 17 May 2007 16:49:11 -0300 To: Ian Lance Taylor Cc: "Daniel Berlin" , "Mark Mitchell" , "Mike Stump" , "Zdenek Dvorak" , gcc-patches@gcc.gnu.org Subject: Re: [patch] Move loop structures to gc memory References: <20070513180823.GA25352@kam.mff.cuni.cz> <20070514230252.GA27051@caradoc.them.org> <20070515021402.GA3168@caradoc.them.org> <464A5CCB.4020000@codesourcery.com> <4aca3dc20705160854o5336457eua905c36296da9bd3@mail.gmail.com> <4aca3dc20705162130u63072e84q148b4d96677b2568@mail.gmail.com> From: Alexandre Oliva Errors-To: aoliva@oliva.athome.lsd.ic.unicamp.br Date: Thu, 17 May 2007 19:50:00 -0000 In-Reply-To: (Ian Lance Taylor's message of "17 May 2007 07\:37\:49 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg01149.txt.bz2 On May 17, 2007, Ian Lance Taylor wrote: > 1) It is cheaper to call pool_alloc than it is to call ggc_alloc. > *_alloc will be called far more often than the walking function. > pool_alloc will provide contiguous memory which will make > traversing the basic blocks--a common operation in gcc--cheaper. > 2) When you do walk, the walking function is going to be cheaper at > runtime if the structures being walked are allocated contiguously. Which once again brings to the point that the issue is not so much whether memory is in the GC memory pool or not, but rather to how it's allocated. If we could allocate object pools in GC memory such that they are contiguous and a single allocation is involved, then ggc_alloc might still be more expensive than pool_alloc, and so much so that the need to register and deregister the object as a root wouldn't make up for it. It just so happens that the GGC design doesn't make it exactly trivial to manage pools of objects. The other take-out point is that ggc_alloc seems to suck rocks, so perhaps improving it should have much higher priority than moving stuff out of GC memory, since this would then benefit everything else *while* accomplishing the goal of speeding up manual memory management, such that the issue of whether or not the object is in GC memory (a mere consequence of the allocation function was selected to allocate it) becomes less relevant. >> I don't see what stops you from constructing say an obstack in GC >> memory. What are the obstacles you see? > The GC code needs to know the complete type of every object you put > into GC, For PCH, yes. For GC only, all we need is the ability to walk such objects and mark those referenced from it. This might require some additional meta-information, but it's far from unworkable. Of course just using an obstack or some such is trivial in comparison, but when you take into account that pointing to GC objects requires you to explicitly register and deregister every pointer to GC objects stored in the obstack, you realize that this is the same additional meta-information mentioned in the previous paragraph. How to express it is "just a matter of programming" ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}