From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29360 invoked by alias); 18 Oct 2011 17:14:18 -0000 Received: (qmail 29349 invoked by uid 22791); 18 Oct 2011 17:14:16 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC,TVD_RCVD_IP X-Spam-Check-By: sourceware.org Received: from 195-14-0-142.nuxit.net (HELO de558.ispfr.net) (195.14.0.142) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 Oct 2011 17:13:59 +0000 Received: from ours.starynkevitch.net ([213.41.244.95] helo=glinka.lesours) by de558.ispfr.net with smtp (Exim 4.72) (envelope-from ) id 1RGDEj-0005qd-IS; Tue, 18 Oct 2011 19:13:57 +0200 Date: Tue, 18 Oct 2011 17:41:00 -0000 From: Basile Starynkevitch To: Ian Lance Taylor Cc: gcc@gcc.gnu.org Subject: Re: adding destroyable objects into Ggc Message-Id: <20111018191350.470cd6b1cd291373d5ff3f2c@starynkevitch.net> In-Reply-To: References: <20111018171201.361304028ab94f102f827bd2@starynkevitch.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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/msg00284.txt.bz2 On Tue, 18 Oct 2011 09:35:16 -0700 Ian Lance Taylor wrote: > [...] I understand that you want to take advantage > of the gcc garbage collector for the MELT plugin. However, in my ideal > world you should be planning for the MELT plugin to take over garbage > collection entirely, rather than relying on gcc's garbage collector. Historically, it was the opposite: I do recognize the importance of garbage collection, and because of the importance of Ggc in GCC, I designed MELT garbage collection above Ggc. Still, I find strange that while some very smart & nice GCC guys want to get rid of Ggc, no patch made into the trunk towards that goal (which I Basile dislike and don't share, so don't expect me Basile to work on this.). Isn't the fact that Ggc is still useful (despite it numerous shortcomings) & widely used in Gcc a signal, or a symptom, of its utility? If Ggc is useless, why is it still here? Why didn't we saw lots of patches to get rid of it? My strong belief is that any *big* compiler needs some automated way to deal with memory (including circular references, which auto_ptr is not very happy about). It can be Ggc (I am not very happy of it) or something else. But again, if many people (not me Basile) believe that Ggc is useless, why is it not disappearing from the GCC trunk? And in my perception, auto_ptr are a poor man's way of implementing a garbage collection, it is not a way to avoid it. Obviously, if I want MELT to stay, I will adapt it to whatever memory management strategy GCC is using (otherwise MELT becomes useless). Indeed, if GCC switches to a fully manual memory management (where every pointer is obtained by new and released by delete, in C++ parlance) I might change the MELT runtime to have its own Gc following such a rule (which I find inadequate for a large software like GCC). But I won't put any effort in removing automatic memory management from GCC, because in my view it would be a tragic mistake: most newcomers to GCC won't be able to write new code... My point is totally independent of MELT: having some automatic way to deal with memory management ease the work of GCC developers (in particular of newbies) and increase the productivity of new GCC developers. On the contrary, requiring new developers to be able to code without bugs all the delete statements (in C++ parlance) is a big impediment [in particular because a compiler does have circular references, and some of the circularities are global to the compiler, not local to a single pass]. 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 mine, sont seulement les miennes} ***