From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14108 invoked by alias); 1 Aug 2008 05:38:39 -0000 Received: (qmail 14094 invoked by uid 22791); 1 Aug 2008 05:38:37 -0000 X-Spam-Check-By: sourceware.org Received: from yosemite.airs.com (HELO yosemite.airs.com) (64.13.131.148) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 01 Aug 2008 05:38:19 +0000 Received: (qmail 5744 invoked by uid 10); 1 Aug 2008 05:38:16 -0000 Received: (qmail 28528 invoked by uid 500); 1 Aug 2008 05:38:11 -0000 To: Hilfinger@CS.Berkeley.EDU Cc: gdb@sourceware.org Subject: Re: GDB to C++ issue: deletion References: <200807312204.m6VM4JQM007611@tully.CS.Berkeley.EDU> From: Ian Lance Taylor Date: Fri, 01 Aug 2008 05:38:00 -0000 In-Reply-To: <200807312204.m6VM4JQM007611@tully.CS.Berkeley.EDU> (Paul Hilfinger's message of "Thu\, 31 Jul 2008 15\:04\:19 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00000.txt.bz2 Paul Hilfinger writes: > This reminded me of an issue that I'd be curious to see discussed. > The STL container classes are certainly convenient for decreasing > memory leaks with little fuss, but they do so internally with > individual frees of allocated items. GDB currently does much of its > allocation using a region-based style (in the form of obstacks). This > reduces leakage at some expense in safety (although I have not seen > many dangling-pointer problems triggered premature obstack releases in > GDB). Allegedly, GDB's use of obstacks significantly speeds up > allocation and (of course) deletion. I have certainly seen programs > in which the need to free data structures individually adds > significant cost*. The STL container classes provide for allocators, > but I have no experience in how well they could be made to work in > duplicating GDB's current performance in this area. It's fairly easy to use a custom allocator for an STL object which allocates from a memory pool. libstdc++ has one. The free function simply adds the pointer to a free list. You wouldn't want to use that specific allocator, since it loses performance by being multi-thread safe. But it would be easy to simplify it. Lots of code which uses obstacks doesn't actually free anything at all. It wouldn't really work to duplicate the semantics of obstack_free in an allocator (free the specified object and all objects allocated after it). But it would be easy to simply ignore calls to free--just make the allocator's deallocate function do nothing. In that case the memory would not go away until the allocator itself is destroyed--or, if you prefer, the allocator could be written to simply never release the memory at all. Ian