On Thu, Oct 20, 2011 at 10:38:04AM +0200, Marc Glisse wrote: > On Thu, 20 Oct 2011, Basile Starynkevitch wrote [...] > >Yes, but that precisely is the finalization machinery we are talking about. > > Er, if there is a leak, it means that memory is not referenced > anymore, so it is up to the garbage collector to pick it up. If only > some objects are marked for garbage collection, that may require > some extra steps, but in principle, in the general context of > garbage collection, I don't see why that would require a finalizer.
Suppose someone is coding a new plugin, which adds several passes to GCC (so need the data to be managed by Ggc, because it is not internal to one single pass.). Suppose the plugin is coded in C++, and that it uses some standard C++ collection (e.g. std::vector or std::map) of C++ objects mixing pointers to GTY-ed data (e.g. gimple) and PPL instances (in C++). The data used by the plugin would better be GTY-ed. And it points to both GTY-ed & PPL data, so need to be finalized. Notice that plugins providing several cooperating passes nearly need the data shared between their passes to be Ggc managed & GTY-ed. A finalization mechanism inside Ggc is the first step. The second step is support of some C++ classes by gengtype. Cheers. -- 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} ***
