This is the mail archive of the
mailing list for the GCC project.
Re: RFC: GC allocating everything with a type, part 1
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: "Zack Weinberg" <zack at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org,geoffk at apple dot com,Steven Bosscher <stevenb at suse dot de>
- Date: Sat, 17 Jan 2004 22:47:24 -0500
- Subject: Re: RFC: GC allocating everything with a type, part 1
- References: <email@example.com> <firstname.lastname@example.org>
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
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.
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.
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.
This suffices to dispose of many, although not all, of
the cases where the type doesn't determine the size.