This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC - Alternatives to gengtype
On Wed, Nov 28, 2012 at 11:54 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Wed, Nov 28, 2012 at 11:30:32AM +0100, Richard Biener wrote:
>>
>> Note that I don't think that non-GC is inherently better than GC. In fact,
>> using a GC leads to easier maintainable code. The fact that we are more
>> memory hungry than necessary (and also maybe consume more compile-time
>> than necessary) is because our GC isn't exactly using technology known
>> for 25 years (generational and copying collection come to my mind).
>
>
> I definitely agree with that. And FWIW,
> MELT (http://gcc-melt.org/ has since its beginning a generational
> copying garbage collector above ggc+gengtype, so that is definitely doable.
>
> I would wish that GCC systematically used a generational copying GC scheme.
> However, this requires that the GCC community agree with that goal (and apparently,
> most - or some - people want on the contrary to get rid of GC).
>
> FWIW, C++ may help in having a manageable copying GC inside GCC,
> provided every GCC contributor agree with it. (The hard point is that
> garbage collection deals with a global -non-modular- property of
> the GCC program -liveness of data-, so it is not feasible to introduce
> a generational copying GC progressively or incrementally).
>
> What a precise copying generational GC needs to know is all
> the local (and global) variables containing GC-managed pointer data.
> The important word is *all*, and that means that everyone should agree to
> use it.
>
> We could for instance have a template for every garbage collector local pointer,
> and declare everywhere locals like
> gclocal<tree> pt1, pt2;
> gclocal<gimple> pg;
> we could also have them handled by a preprocessor (Ä la gengtype) and make that something like
> GCLOCAL(tree pt1, pt2);
> GCLOCAL(gimple pg);
>
> Introducing a copying generational scheme would involve perhaps a bigger effort than the vec.h transition, because a lot of GCC source files would have to be somehow modified.
> (there is an economical & social issue here: who is brave enough to spend time to work on that?
> Few people could take the risk to experiment that if an agreement on GC cannot be reached)
We don't need to track local pointers at all as our garbage collection points
are manually chosen (which is probably a very good thing). For a copying
collector all we need is to get rid of the hacks to not mark thing for the
walkers (with GTY((skip))) to improve marking performance because we
know it's referenced from elsewhere. We'd need to instead use a new
GTY((skip-for-marking)) but still consider the reference when copying.
Btw, memory usage improvements by using a copying collector
can be estimated by looking at (or enhancing) our GC statistics.
Btw, I doubt non-GC pools will do better memory-usage wise - they might
improve performance (no collecting) at the cost of a maintainance overhead.
Richard.
> Regards.
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***