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