Re: adding ability to scan few local variables in GGC?

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

Richard Guenther wrote:
> On Mon, Oct 13, 2008 at 7:23 AM, Basile STARYNKEVITCH
> <basile@starynkevitch.net> wrote:
> > Hello All,
> >
> > Andrew Pinski wrote:
> > > On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH
> > > <basile@starynkevitch.net> wrote:
> > > > Hello All,
> > > >
> > > > I am sometimes wishing to be able to scan some few local variables in GCC
> > > > garbage collector, GGC.
> > > The only time I can think of when you want to do that is when the pass
> > > creates lots of garbage.  The only pass I can think of that might
> > > cause that much garbage is the inliner but even then it would only be
> > > make stuff dead rather than creating new data structures which are
> > > dead.
> > >
> > > Can you give a more concrete example of why you want this?
> > Yes, the MELT branch. There is some incomplete documentation on the wiki,
> > and in the MELT branch itself, file gcc/doc/melt.texi.
> [...]
> > In addition, I also do think that a ggc_collect_with_local would be useful
> > to plugins.
>
> It looks like the MELT scheme of garbage collection is simply incompatible
> with the GCC one.  And I don't see a reason to complicate GCC GGC by
> introducing a possibility to scan the stack (you would have to register all
> stack objects as (temporary) roots, otherwise GGCs precise nature would
> break).


I'm not sure to understand the meaning of "MELT GC being incompatible 
with GGC one". On the contrary, it is designed to be compatible, it is 
compatble in practice, and it works quite well.

The point is how should MELT handle unboxed GCC stuff (like gimple_seq 
gimple tree edge ...etc...) which is allocated inside MELT code.

If an ggc_collect_with_local scheme is not possible (but I repeat that I 
find it simpler, more efficient, and even perhaps more elegant), I have 
always the possibility of having static vectors for every such type of 
stuff (ie one vector of gimple, another of gimple_seq, another of 
tree-s, and so forth) and generate code which pushes value there.
Generating code which directly marks (in the GGC collector) stuff would 
be simpler [this means a solution like the ggc_collect_with_local I just 
suggested], but I can do without. By the way, the

So my perception is on the contrary that MELT GC is fully compatible 
with GGC (and this is expected, since MELT was *designed* for 
compatibility with GCC internals; in other words, compatibility with GGC 
is a major design goal of MELT.), so I feel a little surprised by your 
"imcompatible" wording, probably because I did not explain MELT well enough.

My only question was how to make MELT even more compatible for stuff 
allocated in MELT code (this does not yet happen in practice, but it 
could in the future, so it is not my topmost priority for now). So if a 
ggc_collect_with_local is not acceptable (ie patching a bit ggc.c) when 
GCC goes back in stage1 I could live without (using the static vector 
tricks I suggested above). But again, such a solution is simpler to me, 
and I believe it could help plugins.

> otherwise GGCs precise nature would break).

Strico sensu, GGC is not precise enough, precisely (sorry for the poor 
pun on words) because it does not handle at all any local pointers. So I 
won't describe GGC as a precise collector, only as a garbage collector 
precise for global data, and ignoring all local data. This makes a huge 
difference to everyone using GGC, and every GGC user has to be aware of 
this fact (which is documented).

Regards.

PS. English is not a native language for me, so excuse my approximate 
language.


--
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} ***