From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12722 invoked by alias); 5 Aug 2004 18:05:17 -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 12715 invoked from network); 5 Aug 2004 18:05:16 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 5 Aug 2004 18:05:16 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Bsmab-0002l4-9C; Thu, 05 Aug 2004 14:03:41 -0400 Date: Thu, 05 Aug 2004 18:05:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com, ezannoni@redhat.com Subject: Re: [rfa/dwarf/doc] Inter-compilation-unit reference support for partial DIEs Message-ID: <20040805180341.GB9011@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com, ezannoni@redhat.com References: <20040420170855.GA31548@nevyn.them.org> <20040617034201.GD23443@nevyn.them.org> <20040715184431.GA25807@nevyn.them.org> <20040804230536.GA30848@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00126.txt.bz2 On Thu, Aug 05, 2004 at 12:20:45PM -0500, Jim Blandy wrote: > > Okay. I've started to review this. > > One thought on what I understand so far: > > The way read-in compilation units are chained through alternating > 'struct dwarf2_cu' objects and 'struct dwarf2_per_cu_data' nodes is > kind of weird. And the name 'struct dwarf2_per_cu_data' is not > great --- 'struct dwarf2_cu' is also per-CU data. My intention was that dwarf2_per_cu_data is the reference object for all data relating to this CU and for locating this CU, and the dwarf2_cu is for data actually residing in the CU or needed to process the CU. > Would it work to simply place the 'struct dwarf2_cu' objects > themselves directly into the tree, add a 'read_in' flag, and get rid > of dwarf2_per_cu_data altogether? The memory consumption doesn't > seem like it matters: GDB has 300 CU's, so a 300-byte structure per > CU would add up to ~90k. You've been watching memory consumption, > so you can say better than I how this looks. > > Putting the dwarf2_cu objects directly in the tree would also remove > the need for a read_in_chain: you could just walk the whole tree. > The splay tree accessor functions would replace the linked list > wrangling. I don't think eliminating read_in_chain would be a good idea. Yes, the list wrangling is a bit hairy, but this way we can deal with the cached compilation units instead of walking the entire splay tree. We age compilation units after each CU is processed; walking the tree would be quadratic in the number of compilation units, while the number cached is generally bounded. Also walking the splay tree is very expensive, because that involves splaying the tree - there are no parent pointers in the splay nodes. Our splay trees are not a marvel. As for merging dwarf2_per_cu_data and dwarf2_cu... Monotone, with duplicate elimination turned on, has a bit over a thousand compilation units. There should probably be more, but not a lot more. Without elimination it has only 136. I'm not sure how many glibc would have; without it has 1124, so with possibly as many as eight thousand. So an extra 2MB. [On my branch dwarf2_cu is a lot bigger, but that change won't make it to mainline. I put the die_ref_table in the cu instead of on the comp_unit_obstack because I didn't have a comp_unit_obstack at the time, IIRC.] 2MB isn't a lot and I can probably cut it down further - for instance almost a third of that space is ftypes, and there could trivially be one of these per language per objfile instead. So I can merge the two structures if you would like. I can't think of any fundamental problem. -- Daniel Jacobowitz