Work on gc-improv branch

[Laurynas Biveinis <laurynas dot biveinis at gmail dot com>]

Hi all,

I saw that folks on IRC were wondering about branch commits that were
not posted to gcc-patches. I was planning to emerge from stealth mode
once the branch had something that could be useful for trunk, but
since there is interest I will post status and plans now.

Right now there are three things ongoing on gc-improv branch:

1) Stop abusing current GC by allocating structures there that GC
knows nothing about, i.e. there is never a path from GC roots to any
variables of that type and so gengtype does not produce markers it.
With current GC implementation, doing such allocation has an effect of
doing scratch allocation because it will get collected on next
ggc_collect. Which means: 1) you have to be careful where you put your
ggc_collect calls (quite nasty IMHO) 2) the lifetime of such objects
is usually very clear, so they should be in some obstack or pool,
hopefully increasing data access locality as well.
So I am moving such data from GC memory to obstacks. IMHO this is
immediately useful for trunk too and so I will post patches as soon as
I am done with them.
BTW, it does not deal with types that in some instances have variables
allocated in proper GC way (with a path from GC root) and in some
instances not. Fixing these is going to be hard.

2) Make GC allocation interface aware of types it allocates. This
means replacing
foo * x = ggc_alloc (sizeof (foo))
to
foo * x = ggc_alloc_foo();
and patching gengtype to produce all those ggc_alloc_foo() allocators,
also with options for cleared, vector, and variable size type
allocation and with some kludges for splay trees where allocator has
to be passed as a callback.

This is a prerequisite for my future GC plans of advanced GC
implementation that will need to know type of object given its
address. Also it has a nice side effect of enforcing that GC is used
only with types that it knows something about (see 1) above).

I'd love to see this merged to trunk in near future too but I expect
that right now it would be seen as an arbitrary and annoying change by
developers, especially since nothing in GC implementation right now
makes use of it.

3) gengtype type information dump support, extremely useful for
gengtype debugging IMHO. I already posted it on August 2nd but
surprisingly I cannot find it in archives, so I will repost it in a
moment.

Also, on IRC someone mentioned the project of using Boehm's GC as a GC
implementation for GCC proper. That was mostly done three years ago in
my GSoC project. The status of it was that simple drop-in replacement
without any tuning resulted in about one third slower GC. With
simple-to-intermediate tuning I was able to get it to roughly the same
speed as ggc-page but slightly worse memory usage. There was room for
some advanced tuning and I have tried to take advantage of Boehm's GC
custom marker support. And got stuck there.

Any feedback is most welcome,
-- 
Laurynas