From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8432 invoked by alias); 17 May 2007 04:18:27 -0000 Received: (qmail 8405 invoked by uid 22791); 17 May 2007 04:18:25 -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 04:18:20 +0000 Received: (qmail 10271 invoked from network); 17 May 2007 04:18:17 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 May 2007 04:18:17 -0000 Message-ID: <464BD781.4030509@codesourcery.com> Date: Thu, 17 May 2007 04:18: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> <464BA2D7.2090906@codesourcery.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/msg01098.txt.bz2 Alexandre Oliva wrote: >> In our current system, you must GC-allocate this temporary memory. > > This doesn't seem like the single root cause of the problem to me. > > AFAICT, the root cause of the problem is that you can't dynamically > register and deregister GC roots. It's both. :-) You've nailed one of the key problems: you need to dynamically register and deregister roots. But, one of the reasons you need that ability is precisely so that you can have the roots live in non-GC memory, so that you can use faster allocation/deallocation methods. What you want to do is like: struct s { ... tree t; ... }; struct s* p = some_alloc (sizeof (s)); p->t = build1 (...); ggc_register_root (&p->t); ... ggc_collect (); ... ggc_deregister_root (&p->t); some_free (p); In order to be able to use some_{alloc,free} (presumed to be faster, or otherwise better, that ggc_alloc/ggc_free), you have to have ggc_{register,deregister}_root. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713