Basile STARYNKEVITCH wrote:
Richard Guenther wrote:
Plugins shouldn't keep permanent references to GCed memory. At least
that would make it unnecessary to do what you suggest.
I strongly disagree with that, and I simply do not understand your
position. In my perception, plugins are essentially loaded (dlopen-ed)
but never unloaded (dlclose-ed; perhaps they would be dlclose-ed when
every thing is done). Why should they not use any GTY stuff? What
makes you think that some features of GCC (like GTY ...) are invalid
inside plugins?
I find your position as extreme as saying: plugins should never call
malloc or xcalloc, or should never call warning_at, or should never
call XXX! Why?
So what are plugins for?
I really think we should provide some usage scenarios for plugins.
For argumenting GTY-ed static data in plugins, I would just mention some of the
reasons GTY-ed data are already used in GCC.
First, most of us do know that a real garbage collector is the only way to
manage complex data structures (with circularities, many kind of cross
references, complex reference graph, ...). There is a reason why Lisp, Java,
ML, ... have garbage collectors for several dozens of year, and GCC is becoming
such a complex beast that GC is unavoidable.
[BTW, I am surprised that while some people are advocating recoding GCC in C++,
nobody suggested to recode it in Java or C#]
And if garbage collection is avoidable in GCC, given the strong opposition it has, all
the GTY & gengtype stuff would have been removed by now. The mere fact it is
staying here is in my opinion very significant. If GC was not relevant in GCC, GGC
& GTY would have gone long time ago. They didn't!
I find the mere fact that nobody bothered to remove GTY & gengtype from GCC significant,
even if many people (me including) don't like very much the GGC implementation (I would
prefer a systematic way of using a GC, and a rule as strong as "nobody delete data"
except the garbage collector. I do admit that I am quite extremist on memory management. But
memory management are non-modular issues: they are whole program features!).
To be more specific and concrete, many passes use GTY-ed data. It seems that the common scenario is to have some data built in one pass and reused in some other passes. Then there is no easy way to find out who would delete the data,
Now, I don't see why a plugin won't fall in that "pattern". Definitely, some
guy would want to code a plugin which provides eg two or three (not only one) passes in
GCC, all related in the sense that they would operate on some common data. Here a garbage
collector makes sense, and having some GTY-ed data (or a vector) inside a plugin is
definitely relevant.
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} ***
