Re: RFC: GC allocating everything with a type, part 1

[Geoff Keating <geoffk at desire dot geoffk dot org>]

> From: Steven Bosscher <stevenb@suse.de>
> Date: Mon, 19 Jan 2004 11:40:58 +0100

> On Monday 19 January 2004 02:10, Geoff Keating wrote:
> > Steven Bosscher <stevenb@suse.de> writes:
> > > There are at least two types that need to be special-cased (perhaps more,
> > > but I haven't found them yet -- but probably not many).  These are the
> > > types that do not have a fixed size, such as our core types, the unions
> > > rtx_def and tree_node.  The macros for these types accept an extra SIZE
> > > argument as follows:
> > >
> > > #define ggc_alloc_tree_node(SIZE) \
> > >   ggc_alloc_typed(gt_ggc_e_9tree_node, SIZE)
> > >
> > > and
> > >
> > > #define ggc_alloc_rtx_def(SIZE) \
> > >   ggc_alloc_typed(gt_ggc_e_7rtx_def, SIZE)
> > >
> > > I want these defines to be generated automatically, and the only way I
> > > could think of to tell gengtype about these special cases is by adding
> > > an extra GTY parameter, "size_not_fixed".  That's a bit ugly, if people
> > > have other suggestions then let me know please.
> >
> > My preferred solution is to have a parameter that gives the size of
> > the object; if the parameter is not provided, it defaults to sizeof().
> > You couldn't use it in the macros, since you're going to need to read
> > the object in the parameter, and you don't have one before you
> > allocate it; but the presence of the parameter would indicate that the
> > allocation macro can't just use sizeof().  (The actual conte
> ....?  :-)
> 
> I agree that such an extra parameter would be more elegant, but in
> practice it wouldn't work.  We have many places where we unleash some
> really scarly black magic for some tree codes.  My favorites are on
> the tree-ssa branch, like so (NB. phi is a `tree'):
> 
>   len = ideal_phi_node_len (len);
>   size = sizeof (struct tree_phi_node) + (len - 1) * sizeof (struct phi_arg_d);
>   phi = ggc_alloc (size);

That's how the size is originally computed, not how you get it later.
In this case, the size is just

sizeof (struct tree_phi_node) 
  + (PHI_ARG_CAPACITY (%h) - 1) * sizeof (struct phi_arg_d)

and you can compute pretty much every size with no more effort than that.

> To make this work with the extra parameter you'd have to make some
> local functions global, or at least visible from the GC code, and you'd
> have to rewrite/extend tree_size() to handle all tree codes and all
> special cases like the one above.  I would rather not go there.

Yes, you will have to extend tree_size a bit.  I don't think this
would be a bad thing.

> > This would also allow you to avoid the need for ggc_get_size.  I was
> > originally going to implement this for PCH, but ggc_get_size was
> > available, so that was easier.
> 
> Hmm I don't see how.

You can implement ggc_get_size using this new parameter and the type
of the object.  You don't need extra information from the allocator.

>  Note that for the zone collector we already don't
> really need ggc_get_size(), there is a size field in each alloc chunk
> so we don't have to look up page orders (there's no such thing in
> ggc-zone.c) or similar.

So, you wouldn't need this size field any more, saving you 4 or 8
bytes per object.

> For ggc-page, I don't know how you think we
> could get rid of ggc_get_size, or why you want to.  All I'm trying to
> do for now is add type codes to the alloc chunks in the zone collector.
> (I hope we can improve ggc-zone enough that it can be the default on
> systems with mmap and mprotect, and leave ggc-page for the remaining
> targets.)

> > you'd have to write special allocator
> > routines that can be passed to htab_create_alloc and
> > splay_tree_new_with_allocator.
> 
> Or pass the type code for GC allocated data structs.  Or perhaps it's
> not even necessary, I'm not sure yet.  The whole GC system is pretty
> complex.

'pass the type code' how?

> > I recommend you instead ignore the parameters, and treat all hash
> > tables, splay trees, or whatever the same.  If you have the typecodes
> > stored with each allocated object, you don't need to know in advance
> > that this is a 'hash table of constant_descriptor_tree'; you just need
> > to know it's a hash table, and if you need to know the type of a
> > particular element, you can just go look.
> 
> Right.  All we have to do is follow the pointer to each entry.  But
> my concern is that we also have parametrized types that don't contain
> pointers to GC allocated memory.  Like this one:
> 
> dwarf2asm.c:static GTY((param1_is (char *), param2_is (tree))) splay_tree indirect_pool;
> alias.c:  splay_tree GTY((param1_is (int), param2_is (int))) children;
> 
> The param arguments are not in GC memory, so there is no type code to
> look at.

Yes, that's a problem.  You would have to distinguish between the
cases.

> > However, there's another problem you've not noticed yet.  Consider
> > struct emit_status in function.h.  It contains the following field:
> >
> >   rtx * GTY ((length ("%h.x_reg_rtx_no"))) x_regno_reg_rtx;
> >
> > What type are you going to give to the object that this field points
> > to?  You need to mark it, it contains pointers to rtx; but you don't
> > even know how many of them there are without looking at the containing
> > structure.  So you'll need to keep a back pointer.
> 
> I don't think so.  This field is enclosed in a type, so it doesn't have
> its own type code.  The marker for the containing type obviously knows
> how to handle the length parameter.  The rtx'en pointed to by this field
> each have the type code for an rtx, so we know which marker function to
> use here, too.  We don't care about what points to some memory, just
> about the type that is stored in that memory.

I think you missed the '*' in the line above.  This is not a pointer
to a struct rtx_def, it is a pointer to a separately-allocated chunk
of memory that contains pointers to struct rtx_def.  What type does
the separately-allocated chunk have?

-- 
- Geoffrey Keating <geoffk@geoffk.org>