On Thu, Apr 2, 2009 at 12:48 AM, Joern Rennecke <joe...@arc.com> wrote: >> 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.
This looks like a rather uninformed opinion... >> 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! Welcome... to the desert.. of the Real. Once something is in GCC, it is near impossible to get it out again. In this case, the "something" is PCH, which still heavily depends on GGC. That does *not* mean everyone (or even a majority) likes it. And more importantly for this discussion: It also doesn't mean that other, new infrastructure should increases GCC's dependency on the GGC stuff. > I believe it is avoidable, but: > - There is no consensus that it should be avoided, and there are more > important issues to discuss. Exactly! Actually, I think there is more-or-less consensus that it should be avoided if possible. The current GTY machinery forces *everything* into GC memory, mostly just to avoid broken PCH. But that is a problem with the design/implementation of the GGC stuff, not necessarily with the concept (obstacks and pools are also not all that...). Some examples: RTL *must* live in GGC memory only for PCH. Likewise with alias set, and most static global variables decorated with a GTY marker. I don't think anyone really likes that. I also don't think anyone is really sure what should be decorated with a GTY marker and what can safely be left undecorated (nobody ever un-decorated anything after the tree-ssa merge, though I would expect some markers are redundant now). > - Even if there was a consensus to avoid it, nobody is willing to but in > the time to change gcc and keep it leak-free (or merely keep memory leaks > at a level comparable to GGC memory overhead). This is easier nowadays than it used to be, when GCC switched from obstacks to garbage collection. Tools like valgrind make life a tad less unfriendly for the debugger. But yes, +1. >> 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. I don't see this scenario really. There is (should be?) almost no data transfer between passes (except the intermediate representation, which obviously has a special position in this discussion). >> Then there is no easy way to find out who would delete >> the data, So Don't Do That (tm). >> 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, And use other types than the types already in GCC itself, and hand that data over across a gcc_collect call? Sounds broken by design to me. At least, I don't think that works for any pass even within GCC itself, so why should it work for plugins? You should not pass data from one pass to another via GC memory, except the call graph and everything that hangs from there (cgraph -> functions -> cfg -> stmts -> operands). As long as you only modify the existing intermediate representation, you don't have to worry about GGC at all! To me, it seems that plugins should be sufficiently self-contained to take care of their own memory management, *without* GGC, except for data that is shared between the plugin and the compiler proper (i.e. the cgraph, etc.). But you seem to imply that your plugin needs to do more than that...? > As long as you only need to GTY known types, you can avoid having extra GTY > roots by having all plugins share one GTY root in the plugin infrastructure; > this root can point to a list to which each plugin can add at will. I don't think this would work. The marker routines wouldn't know what would be in this one root with new types. But, as you said... > If you want new types, it gets ugly, ...there's an understatement! >because how can you independently > develop plugins and avoid collisions? An enum to describe a type > won't be enough anymore, unless you want to go te a really silly width and > statart doling out namespaces. Exactly. How would you write the markers and how would you let the GTY mechanism know which markers to call?? This is all automatically generated from the GCC source now, but I don't see how that woudl work with plugins unless you build the plugin along with GCC (and thereby defeat the purpose of plugins). Write them by hand? More power to you if you even think you *can* do that. Ciao! Steven
