From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16358 invoked by alias); 20 Oct 2011 08:53:49 -0000 Received: (qmail 16347 invoked by uid 22791); 20 Oct 2011 08:53:48 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from smtp-154-thursday.nerim.net (HELO maiev.nerim.net) (194.79.134.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Oct 2011 08:53:25 +0000 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by maiev.nerim.net (Postfix) with ESMTPS id EBFC12E023 for ; Thu, 20 Oct 2011 10:53:24 +0200 (CEST) Received: from basile18 by hector.lesours with local (Exim 4.76) (envelope-from ) id 1RGoNQ-0003Gj-Id for gcc@gcc.gnu.org; Thu, 20 Oct 2011 10:53:24 +0200 Date: Thu, 20 Oct 2011 12:10:00 -0000 From: Basile Starynkevitch To: gcc@gcc.gnu.org Subject: Re: adding destroyable objects into Ggc Message-ID: <20111020085324.GA12472@ours.starynkevitch.net> References: <20111018171201.361304028ab94f102f827bd2@starynkevitch.net> <20111018191350.470cd6b1cd291373d5ff3f2c@starynkevitch.net> <20111020080753.a895eae452bb25e312ebf617@starynkevitch.net> <20111020081245.GA12085@ours.starynkevitch.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00342.txt.bz2 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: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***