Re: mjw/dwarf_output branch

[Mark Wielaard <mjw at redhat dot com>]

On Wed, 2011-02-02 at 13:17 -0800, Roland McGrath wrote:
> > but does raise the question whether we aren't
> > creating objects to match against only to immediately throw them away
> > because they are already in the collector? 
> 
> We are.  AFAICT this is the way STL maps/sets are normally used.  Otherwise
> their interfaces make you do the hashing and table lookup twice, once to
> check if it exists and a second time to insert if it doesn't.

I guess I was somewhat misled by picking dynamic_equality_set as example
since that isn't really a standard STL container, but something where we
use the hash value explicitly and create and search the buckets directly
instead of letting the STL container magic do all that for us.

> The children_type and attributes_type objects are somewhat larger.  And
> those are not the granularities of sharing in the file format.  So the only
> benefit we are getting from independent sharing at those granularities is
> memory savings.

You mean, we mostly do it for the side effect that comes with using a
hashing function to put them into a container, so we don't have to
compare lots of them?

>   For example, there is just one empty children_type object
> in the collector and all debug_info_entry objects share the pointer to
> that.  Likewise for less trivial ones, like an attributes_type of just
> {name="x", type="#ref_to_int"} and a whole children_type for a parameter
> list of (int, int, int) appearing in numerous prototypes' subprogram dies,
> etc.  But it could well be that the memory savings there is not worth the
> computation time to do the two separate hash tables.

I am not clear on what these two separate hash tables are.

> > > It's certainly possible to do it the other way.  You just don't break up
> > > the hash calculation along the lines of the attributes_type/children_type
> > > objects.  Instead, do it all at the entry level.
> > 
> > I am not sure if I understand precisely what you mean here. We certainly
> > need a hash based on the new local hash idea for the attributes_type,
> > since that is where most of the collisions happen now. Do you mean,
> > calculate the local hash for/at the entry/die level, and leave it at
> > that, then use that local hash value in the calculation of the
> > attributes_type hash?
> 
> I guess what I mean is that we would not have separate hash tables for
> attributes_type and children_type objects in the collector (as I just
> mentioned above).  Instead, only the whole debug_info_entry would have its
> hashes collected from the contents of its two constituent containers.

And, so by extension I don't understand this either.
Sorry for being dense.

> It's more like an SML or Modula-3 module signature than like a C++ base
> class, just in case that helps you at all.  And I don't actually know
> Java deeply enough to say whether a Java interface is more like one or
> the other.

Java has generics, which probably are most like templates. Although it
is more a runtime concept than a compile time concept. Interfaces in
more a kind of multiple inheritance, without defining base classes for
the member functions (so they are purely virtual).

I think the most confusing thing about the use of templates in c++ is
that there is no indication anything is a template name, it is mostly
just a random string of characters that looks suspiciously like any
other field, method, class or type name. You must have the word
"typename" in scope, but even then you don't know what is the actual
template name used in the expression. Even searching backwards to the
template definition does mostly not help, since typenames are
"contagious", so if you know the names as defined in the template, you
then have to go look where they are used, and keep iterating
syntactically till you found all the replacement. In most case they just
look like random defines to me. <end rant, sorry about that>

Cheers,

Mark