> 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 believe it is avoidable, but: - There is no consensus that it should be avoided, and there are more important issues to discuss. - 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). > 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. 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. If you want new types, it gets ugly, 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. You could approach it a bit more object-oriented and have a pointer in each object that points to a descriptor for the type. If you define such a type in the plugin infrastructure, it again becomes a special kind of pre-defined type. I suppose the main work will be to get the GTY parser to create the type descriptors for custom types in modules. This e-mail was sent from a group e-mail system of ARC International Plc. Full details of the registered names and addresses of companies within the ARC group can be found on the ARC website.ARC International plc, Registered Office: Verulam Point, Station WaySt. Albans AL1 5HE United Kingdom Registered in England and Wales No. 3592130savm-exch03
