From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31191 invoked by alias); 5 May 2009 02:53:39 -0000 Received: (qmail 31166 invoked by uid 22791); 5 May 2009 02:53:38 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from wf-out-1314.google.com (HELO wf-out-1314.google.com) (209.85.200.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 May 2009 02:53:33 +0000 Received: by wf-out-1314.google.com with SMTP id 25so3112731wfc.14 for ; Mon, 04 May 2009 19:53:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.162.9 with SMTP id k9mr2432483wfe.129.1241492011872; Mon, 04 May 2009 19:53:31 -0700 (PDT) In-Reply-To: <49D44E4B.6060201@starynkevitch.net> References: <20090401224848.GE26057@elsdt-razorfish.arc.com> <49D44E4B.6060201@starynkevitch.net> Date: Tue, 05 May 2009 02:53:00 -0000 Message-ID: <395877250905041953m70a6838et5eda1a027e05533f@mail.gmail.com> Subject: Re: Plugins & GGC ie GTY From: Justin Seyster To: Basile STARYNKEVITCH Cc: Joern Rennecke , Richard Guenther , Taras Glek , "Joseph S. Myers" , GCC Mailing List , Diego Novillo , Le-Chun Wu , Grigori Fursin Content-Type: text/plain; charset=ISO-8859-1 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: 2009-05/txt/msg00072.txt.bz2 Sorry for dragging this discussion out from the distant past. I'm in the process of porting some plug-ins from the old plugin SVN branch to the new plug-in system, and this is one of the issues blocking me. My plug-ins maintain some tree nodes that I want to stay alive from function to function. Managing these nodes manually isn't an option, since they get allocated (with garbage collection) by internal GCC functions. Basically, my plug-in wants to sprinkle logging function calls throughout compiled code. I generate the types and decls for these with build_function_type_list() and build_fn_decl(), and then use them when I need them. Now, I don't _need_ to hold on to these references, but regenerating them every time I use them seems inefficient to me. > We just have to add some small code [2] into the ggc_mark_roots routine of > gcc/ggc-common.c to add the scanning using this gt_ggc_r_gt_FOO_h. This is > not a big deal. We should simply add a routine > ggc_register_plugin_root_tab(const struct ggc_root_tab*) that adds its > argument to some (static variable in gcc/ggc-common.c which is a) linked > list or vector, and have ggc_mark_root scan that list or vector by adding a > few lines there. We require plugin initializers to call > ggc_register_plugin_root_tab appropriatly, exactly like they do already call > register_callback etc... This is in fact exactly the solution I was using in the old plugin branch (though I never submitted the code once it became clear that the newer plug-in system was going to take over). I can send out the patch if anyone is interested; it's as simple as it sounds. With that extra bit of garbage collector support in place, I hacked up a simple header file that provides macros to manually generate ggc_add_plugin_root struct entries just like the ones gengtype would generate (for a small set of types). So a plug-in author can declare a vector of tree nodes like so: static GC_ROOT_TREE_VEC (my_tree_vector); Another macro (to be called from plugin_init()) lets the author register that root with the garbage collector. register_root (my_tree_vector); This isn't an end-all solution, but it actually provides all the support that I need for my plug-ins, and it is perhaps a useful stepping stone. The main reason I'm bringing this up is because I've got a handful of plug-ins I'd like to make public. Without any support from the garbage collector, I'll have to do some rewriting to get around the issue. If other plug-in authors thinks this is a useful idea (would it be sufficient to port MELT, for instance?), I'd be willing to prepare some patches to add it in. --Justin