Re: Plugins & GGC ie GTY

[Basile STARYNKEVITCH <basile@starynkevitch.net>]

Justin Seyster wrote:
>
>   
>> We just have to add some small code [2] into the ggc_mark_roots routine of
>> gcc/ggc-common.c to add the scanning using this gt_ggc_r_gt_FOO_h. This is
>> not a big deal. We should simply add a routine
>> ggc_register_plugin_root_tab(const struct ggc_root_tab*) that adds its
>> argument to some (static variable in gcc/ggc-common.c which is a) linked
>> list or vector, and have ggc_mark_root scan that list or vector by adding a
>> few lines there. We require plugin initializers to call
>> ggc_register_plugin_root_tab appropriatly, exactly like they do already call
>> register_callback etc...
>>     
>
> This is in fact exactly the solution I was using in the old plugin
> branch (though I never submitted the code once it became clear that
> the newer plug-in system was going to take over).  I can send out the
> patch if anyone is interested; it's as simple as it sounds.
>
> With that extra bit of garbage collector support in place, I hacked up
> a simple header file that provides macros to manually generate
> ggc_add_plugin_root struct entries just like the ones gengtype would
> generate (for a small set of types).  So a plug-in author can declare
> a vector of tree nodes like so:
>
> static GC_ROOT_TREE_VEC (my_tree_vector);
>
> Another macro (to be called from plugin_init()) lets the author
> register that root with the garbage collector.
>
> register_root (my_tree_vector);
>
> This isn't an end-all solution, but it actually provides all the
> support that I need for my plug-ins, and it is perhaps a useful
> stepping stone.
>
> The main reason I'm bringing this up is because I've got a handful of
> plug-ins I'd like to make public.  Without any support from the
> garbage collector, I'll have to do some rewriting to get around the
> issue.  If other plug-in authors thinks this is a useful idea (would
> it be sufficient to port MELT, for instance?), I'd be willing to
> prepare some patches to add it in.
>
>   


I think the major issue is not to code the patch. It is to have it 
accepted in the trunk. My perception is that many people dislike GGC and 
reject the whole idea of garbage collection inside GCC [1] For example, 
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00431.html was a small 
[rejected] patch which would have provide the equivalent functionality.

I definitely dream of making MELT a plugin. What I need for this is

a. The ability to add a few (perhaps only 2 or 4) static or global GGC 
roots inside a plugin. One of these roots has a very special scanning 
routine.

b. The ability to add a few GTY-ed types. This would require essentially 
a patch to gengtype to have it run in a plugin mode where it take one 
single foo.c source files with GTY as input and output one single 
gt-foo.h file with the scanning/marking routine.

c. The ability to have a custom scanning/marking routine. This I could 
perhaps do with a #define gt_ggc_mx_FOOTYPE(Root) my_marking_rootine(Root)

The main reason of all this is that MELT does have its own GC backed up 
by GGC, and that MELT handle all its local pointers appropriately (in 
generated C code, this is quite easy: just hack the C generator). So in 
the infrequent case (only full MELT garbage collection, since the minor 
MELT GC is handled by MELT using a copying strategy) when GGC is called, 
a special routine has to mark all the local pointers. Remember that MELT 
is a Lisp dialect translated to C: you don't handle explicitly any GC 
local roots in MELT code, they appear only in the generated C code.

Also, GGC is perhaps more associated -in the mind of most people here- 
with precompiled headers than with memory management. MELT is not 
compatible with precompiled headers (in the sense that they could not be 
generated by MELT stuff; however, one could imagine loading some 
precompiled headers before using some MELT pass). My belief is that 
precompiled headers and plugins [2] are not really compatible (I am 
thinking of generating a *.gch file using plugins, I am not thinking of 
reading a *.gch file using a plugin; that should be already ok), and 
both are rarely used (so will probably be even less often used 
together). The insight is that there is no way to guarantee that a 
plugin would restore its entire state (at time of *.gch writing) when 
reading again the *.gch

Regards

Note [1]: my opposite view is that garbage collection is a 
whole-program-wide feature which is required in any sufficiently complex 
compiler (so I believe it is here to stay) but that GGC is not the 
garbage collector I'm dreaming (mostly because it does not handle local 
roots), burt barely enough for me. I am aware that my position is in the 
minority.

Note [2]: See the 
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02233.html thread

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