From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12045 invoked by alias); 5 Feb 2004 23:20:06 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11994 invoked from network); 5 Feb 2004 23:20:01 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 5 Feb 2004 23:20:01 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id B6BAA1A4412; Thu, 5 Feb 2004 18:16:55 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16418.52967.149289.557083@localhost.redhat.com> Date: Thu, 05 Feb 2004 23:20:00 -0000 To: Daniel Jacobowitz Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: RFA: Don't use obsavestring in dwarf2read In-Reply-To: <20040205204756.GA2465@nevyn.them.org> References: <20040112015726.GA7151@nevyn.them.org> <20040202182218.GA3405@nevyn.them.org> <16418.39156.566837.685666@localhost.redhat.com> <20040205194821.GA30363@nevyn.them.org> <16418.43222.486879.784465@localhost.redhat.com> <20040205204756.GA2465@nevyn.them.org> X-SW-Source: 2004-02/txt/msg00113.txt.bz2 Daniel Jacobowitz writes: > On Thu, Feb 05, 2004 at 03:34:30PM -0500, Elena Zannoni wrote: > > > The obstacks themselves are probably a good idea. Once upon a time, > > > Peter informed me, there was a plan to free the psymbol obstack when > > > all symbols had been read in; but that doesn't seem like a useful > > > optimization, and I can't think offhand of any use for separate symbol > > > and type obstacks. I wouldn't object to having a per-objfile obstack > > > instead, and un-seperating them. > > > > I think it would be worthwhile to see how much doing that would save us. > > Well, it wouldn't save anything by itself - there's immeasurable > overhead to the obstacks. It would let us eliminate this sort of > duplication, but they're pretty tricky to identify; it took me a couple > of hours to convince myself about this set of 'em. > I meant in general, yes. Since the possible 'shorcuts' are difficult to identify, and they are only for dwarf2 (that I've looked at) I am bit worried about the cross pointers. I am thinking to kill the triad. > > > > [BTW why are only few obstack properly initialized?] > > > > > > Which do you mean? > > > > > > > I grepped for obstack_init, and only a few obstacks call that > > function. Form the obstack doco, it seems that it needs to be > > called. I wonder if the function was introduced later on in libiberty, > > as an afterthought. > > It looks like obstack_specify_allocation and obstack_init fill the same > role. The objfile's obstacks use the former. > Which is dumb: # define obstack_init(h) \ _obstack_begin ((h), 0, 0, \ (void *(*) ()) obstack_chunk_alloc, (void (*) ()) obstack_chunk_free) # define obstack_specify_allocation(h, size, alignment, chunkfun, freefun) \ _obstack_begin ((h), (size), (alignment), \ (void *(*) ()) (chunkfun), (void (*) ()) (freefun)) all the calls to obstack_specify_allocation use xmalloc and xfree, but we also have: /* Unless explicitly specified, GDB obstacks always use xmalloc() and xfree(). */ #define obstack_chunk_alloc xmalloc #define obstack_chunk_free xfree There is only a call to obstack_specify_allocation that specifies size and alignment. I'd prefer them to use just one method. I'll clean up some. > > Ah, ok, it's because of the nature of the program you were handling. I > > was trying to imagine how the overhead of obstack themselves could be > > that large. It seems to me that this is a good argument for an 'on > > demand' symbol reading implementaion. But, yes the various dwarf2 > > sections are already in the psymbol_obstack. And we are duplicating > > that again on the type_obstack. :-( > > Right. I'm not sure how much of this can be done on demand that isn't > already; if I wasn't clear about this, the 100MB was a worst-case > number (-readnow). Without -readnow it's much less. > ah. Yep, you didn't mention readnow.