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
