Re: [rfa/dwarf/doc] Inter-compilation-unit reference support for partial DIEs

[Daniel Jacobowitz <drow@false.org>]

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