Re: Plugins & GGC ie GTY

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

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