This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: adding destroyable objects into Ggc


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]