From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16505 invoked by alias); 19 Oct 2011 07:43:02 -0000 Received: (qmail 16493 invoked by uid 22791); 19 Oct 2011 07:43:01 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TO_NO_BRKTS_PCNT,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from smtp1.u-psud.fr (HELO smtp1.u-psud.fr) (129.175.33.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Oct 2011 07:42:45 +0000 Received: from smtp1.u-psud.fr (localhost [127.0.0.1]) by localhost (MTA) with SMTP id 29C092506D3 for ; Wed, 19 Oct 2011 09:42:42 +0200 (CEST) Received: from matups.math.u-psud.fr (mathups.math.u-psud.fr [129.175.52.4]) by smtp1.u-psud.fr (MTA) with ESMTP id 0EB802506A3 for ; Wed, 19 Oct 2011 09:42:42 +0200 (CEST) Received: from barah.math.u-psud.fr (barah.math.u-psud.fr [129.175.52.24]) by matups.math.u-psud.fr (Postfix) with ESMTP id 07FAC7541 for ; Wed, 19 Oct 2011 09:42:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by barah.math.u-psud.fr (Postfix) with ESMTP id 05E37474062 for ; Wed, 19 Oct 2011 09:42:42 +0200 (CEST) Received: from barah.math.u-psud.fr ([127.0.0.1]) by localhost (barah.math.u-psud.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86jT17QSREYq for ; Wed, 19 Oct 2011 09:42:40 +0200 (CEST) Received: from [127.0.0.1] (topodyn-ng.math.u-psud.fr [129.175.50.33]) by barah.math.u-psud.fr (Postfix) with ESMTP id 5177347405D for ; Wed, 19 Oct 2011 09:42:39 +0200 (CEST) Message-ID: <4E9E7F6F.8050601@free.fr> Date: Wed, 19 Oct 2011 13:31:00 -0000 From: Duncan Sands User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111005 Icedove/3.1.15 MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: Re: adding destroyable objects into Ggc References: <20111018171201.361304028ab94f102f827bd2@starynkevitch.net> <20111018191350.470cd6b1cd291373d5ff3f2c@starynkevitch.net> <20111019080021.4e1acb3687fc8ceacc2fd7a3@starynkevitch.net> <20111019082210.3834624fc4dc8734fd6337c6@starynkevitch.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00316.txt.bz2 Hi Gabriel, >> I also agree with you that GCC architecture is messy, and that scares newscomer a lot. >> > > Yes, but the way we improve it isn't, in my opinion, adding more GC. > First we would like to remove complexity, and I do not think we should > start by focusing on storage management until we get a clearer idea > about lifetime of data structures we manipulate and how they mesh. > We might find out (as I suspect) that the builtin GC of C (or C++) is > remarkable at the job, provided we have a design that makes the > lifetime obvious and take advantage of it. what you say sounds very sensible to me. If you look at LLVM, most memory management is done by using container objects (vectors, maps etc) that automatically free memory when they go out of scope. This takes care of 99% of memory management in a clean and simple way, which is a great situation to be in. Ciao, Duncan.