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

[Daniel Berlin <dberlin at dberlin dot org>]

On Jan 17, 2004, at 11:36 PM, Zack Weinberg wrote:

> Daniel Berlin <dberlin@dberlin.org> writes:
>
> > > Would it not be appropriate to have separate type codes for every rtx
> > > and tree code?
> >
> > There are a few problems with doing that i can think of off the top of
> > my head that pretty much make it infeasible.
> >
> > 1. gengtype doesn't generate type codes like that, so we'd have to
> > make up a hackish way to include them in the gtype file by puttering
> > around in tree.def
>
> I don't see a quick way around this, you're right...

This is actually the blocker from doing it, i believe.
:(

> > 2. This would require, among other things, large numbers of
> > modifications all over the place (because everything that uses
> > ggc_alloc_tree/rtx, including things that use it for a variety of
> > tree/rtl codes, would have to have some large switch.
>
> ... this isn't a problem; we just need a table mapping tree/rtx codes
> to type codes ...

Huh?
ggc_alloc_tree doesn't take a code, it takes a size, so you'd still 
have to add code everywhere we call ggc_alloc_tree.
Maybe there aren't as many uses of that as i think.

> > 3. The only thing that these extra typecodes buy you is the ability to
> > segregate different types of trees into different places.  Most trees
> > that are allocated around the same time should be close together in
> > memory, even if they are of different sizes.
> > That's why i moved trees into the tree zone, rather than trying to
> > further split up the tree zone.
>
> ... this isn't quite true ...

Given. I'm sure you can think of other advantages (I assume that's the 
part you are disagreeing with).

> > 4. The only immediate advantage to type coding everything to be able
> > to determine what marker routine to call on a given chunk of memory
> > (if we stop and restart marking, for example).  You just need that
> > code i had discussed with you once that generates an array mapping
> > typecodes to marker routines (remember when i was trying to figure out
> > an easy way to make sure the marking routines that only existed in
> > some languages didn't get pulled into the common gtype-desc.h file,
> > where the arrays were going to be?)
> >
> > In this light, the tree marker knows how to mark all types of trees,
> > so we'd end up calling the same marking routine even if the type codes
> > were different anyway.
>
> ... consider how much simpler that tree marker would be if it didn't
> need to handle every last different kind of tree.  Lots of small
> functions with straight-line code instead of one big one with a lot of
> conditionals.  One of the things I'm interested in is clever logic to
> avoid recursion entirely in the marker.


Hmmm.
True enough, but i think that's well beyond the scope of what Steven is 
trying to do ATM.

> zw