From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23663 invoked by alias); 17 May 2007 00:33:38 -0000 Received: (qmail 23656 invoked by uid 22791); 17 May 2007 00:33:37 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 May 2007 00:33:35 +0000 Received: (qmail 1107 invoked from network); 17 May 2007 00:33:33 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 May 2007 00:33:33 -0000 Message-ID: <464BA2D7.2090906@codesourcery.com> Date: Thu, 17 May 2007 00:33:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Alexandre Oliva CC: Daniel Berlin , Ian Lance Taylor , 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> <20070514223217.GA23691@caradoc.them.org> <20070514230252.GA27051@caradoc.them.org> <20070515021402.GA3168@caradoc.them.org> <464A5CCB.4020000@codesourcery.com> <4aca3dc20705160854o5336457eua905c36296da9bd3@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg01093.txt.bz2 Alexandre Oliva wrote: > This bit is mostly a matter of drawing the line of what it means to be > GC memory or not (as in, is it GC-allocated or just GC-walkable). Rather, between GC-allocated and points-to-GC-allocated. The point is that these are logically distinct concepts; our implementation conflates them. To see why this is undesirable, consider suppose that you want to allocate some temporary memory, which an obvious lifetime, which will point to TREEs. Some of the TREEs may be pointed to *only* from this temporary memory. You want to be able to run the collector while this temporary memory is allocated. So, it's important that the GC system know that there are roots in this temporary memory. In our current system, you must GC-allocate this temporary memory. (For example, you can't use alloca, or obstacks, both of which are very fast allocation schemes.) Then, when you're done with the temporary memory, you must wait for the collector to collect it -- or explicitly ggc_free it. If you're in the camp that wants to avoid ggc_free, you have to wait for this memory to be collected, by which point you'll probably have allocated more stuff, which could have been more efficiently put in the in-cache now-garbage memory, but wasn't put there because that memory hadn't been collected yet. If you're willing to use ggc_free, you can reclaim the memory in timely fashion, and thus avoid the locality problem, but you still have to use our relatively expensive GC-allocation/deallocation functions, rather than the more efficient alloca/obstack (or, even, probably, malloc) family of functions. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713