From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28127 invoked by alias); 21 Oct 2011 08:43:47 -0000 Received: (qmail 28111 invoked by uid 22791); 21 Oct 2011 08:43:46 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-gy0-f175.google.com (HELO mail-gy0-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Oct 2011 08:43:30 +0000 Received: by gyc15 with SMTP id 15so4091648gyc.20 for ; Fri, 21 Oct 2011 01:43:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.73.7 with SMTP id h7mr903341obv.51.1319186609350; Fri, 21 Oct 2011 01:43:29 -0700 (PDT) Received: by 10.182.12.202 with HTTP; Fri, 21 Oct 2011 01:43:29 -0700 (PDT) In-Reply-To: <20111021080914.08528e83f5eb53897d92fee9@starynkevitch.net> References: <20111018171201.361304028ab94f102f827bd2@starynkevitch.net> <20111018191350.470cd6b1cd291373d5ff3f2c@starynkevitch.net> <20111020080753.a895eae452bb25e312ebf617@starynkevitch.net> <20111020081245.GA12085@ours.starynkevitch.net> <20111020085324.GA12472@ours.starynkevitch.net> <20111021080914.08528e83f5eb53897d92fee9@starynkevitch.net> Date: Fri, 21 Oct 2011 12:28:00 -0000 Message-ID: Subject: Re: adding destroyable objects into Ggc From: Richard Guenther To: Basile Starynkevitch Cc: gcc@gcc.gnu.org, Marc Glisse Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00377.txt.bz2 On Fri, Oct 21, 2011 at 8:09 AM, Basile Starynkevitch wrote: > On Thu, 20 Oct 2011 17:13:46 +0200 (CEST) > Marc Glisse wrote: > >> Can't you use GTY-ed memory in PPL? Sorry for the naive question, but >> std::vector can take an allocator parameter, gmp lets you specify an >> allocation function... > > > I believe that the PPL C++ code don't have any kind of allocator paramete= rs. > > But I am not sure it would help. Let's take just a std::string allocated = with an > allocator that would use Ggc-ed memory, and appearing inside a GTY-ed dat= a. > How that Ggc-ed memory used for the string will be marked, and how will i= t be released? > > The usual way to release memory allocated by Ggc is inside ggc_collect (e= .g. by > sweep_pages) and that happens when the object has not been marked (becaus= e Ggc is a > precise mark&sweep collector). > > And because C++ collections don't offer (AFAIK) any support to scan all t= heir internal > data (so if std::string implementation actually contains a pointer to som= e internal > buffer which would have been Ggc-allocated because the string has been cr= eated using > our putative Ggc C++ allocator) it seems to me that the only way to make = it work is to > have the C++ destructor of our std::string called from inside Ggc. This i= s what I call > finalized objects (or destroyable objects) inside Ggc. Nor do C collections, thus we explicitely have code that deals with this (auto-generated from gengtype). For C++ this can get slightly more elegant by template class GgcWalk { void walk(void) { /* By default nothing */ }; } and providing specializations for each container you want to track in GC me= mory. That specializations could in turn be autogenerated by gengtype or explicit= ly written. So there is no inherent limitation with the GGC machinery. > Or did I not understood something about your question? > > Cheers > > -- > Basile STARYNKEVITCH =A0 =A0 =A0 =A0 http://starynkevitch.net/Basile/ > email: basilestarynkevitchnet mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mine, sont seulement les miennes} *** >