From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23110 invoked by alias); 1 Apr 2009 22:49:16 -0000 Received: (qmail 23102 invoked by uid 22791); 1 Apr 2009 22:49:15 -0000 X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,J_CHICKENPOX_73,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service1-us.mimecast.com (HELO service1-us.mimecast.com) (207.211.31.11) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 01 Apr 2009 22:49:11 +0000 Received: from savm-exch03.arc.com (mailgate-sa02.arc.com [83.244.211.73]) by service2-us.mimecast.com; Wed, 01 Apr 2009 18:48:59 -0400 Received: from smtp-uk.arc.com ([172.17.8.221]) by savm-exch03.arc.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Apr 2009 23:48:48 +0100 Received: by smtp-uk.arc.com (sSMTP sendmail emulation); Wed, 1 Apr 2009 23:48:48 +0100 From: "Joern Rennecke" Date: Wed, 01 Apr 2009 22:49:00 -0000 To: "Basile STARYNKEVITCH" Cc: "Richard Guenther" , "Taras Glek" , "Joseph S. Myers" , "GCC Mailing List" , "Diego Novillo" , "Le-Chun Wu" , "Grigori Fursin" Subject: Re: Plugins & GGC ie GTY Message-ID: <20090401224848.GE26057@elsdt-razorfish.arc.com> MIME-Version: 1.0 Content-Class: urn:content-classes:message User-Agent: Mutt/1.4.2.2i X-MC-Unique: 109040118485902002 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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: 2009-04/txt/msg00078.txt.bz2 > And if garbage collection is avoidable in GCC, given the strong oppositio= n it has, all the GTY & gengtype stuff would have been removed by now. The = mere fact it is staying here is in my opinion very significant. If GC was n= ot relevant in GCC, GGC & GTY would have gone long time ago. They didn't! I believe it is avoidable, but: - There is no consensus that it should be avoided, and there are more important issues to discuss. - Even if there was a consensus to avoid it, nobody is willing to but in the time to change gcc and keep it leak-free (or merely keep memory leaks at a level comparable to GGC memory overhead). > To be more specific and concrete, many passes use GTY-ed data. It seems t= hat the common scenario is to have some data built in one pass and reused i= n some other passes. Then there is no easy way to find out who would delete= the data, >=20 > Now, I don't see why a plugin won't fall in that "pattern". Definitely, s= ome guy would want to code a plugin which provides eg two or three (not onl= y one) passes in GCC, all related in the sense that they would operate on s= ome common data. Here a garbage collector makes sense, and having some GTY-= ed data (or a vector) inside a plugin is definitely relevant. As long as you only need to GTY known types, you can avoid having extra GTY roots by having all plugins share one GTY root in the plugin infrastructure; this root can point to a list to which each plugin can add at will. If you want new types, it gets ugly, because how can you independently develop plugins and avoid collisions? An enum to describe a type won't be enough anymore, unless you want to go te a really silly width and statart doling out namespaces. You could approach it a bit more object-oriented and have a pointer in each object that points to a descriptor for the type. If you define such a type in the plugin infrastructure, it again becomes a special kind of pre-defined type. I suppose the main work will be to get the GTY parser to create the type descriptors for custom types in modules.=20 This e-mail was sent from a group e-mail system of ARC International Plc. F= ull details of the registered names and addresses of companies within the A= RC group can be found on the ARC website.ARC International plc, Registered = Office: Verulam Point, Station WaySt. Albans AL1 5HE United Kingdom Registe= red in England and Wales No. 3592130savm-exch03=20 =20 =20 =20 =20 =20 =20 =20