From patchwork Mon May 16 00:13:56 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicola Pero X-Patchwork-Id: 95670 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 36101B6EF1 for ; Mon, 16 May 2011 10:14:39 +1000 (EST) Received: (qmail 25885 invoked by alias); 16 May 2011 00:14:27 -0000 Received: (qmail 25857 invoked by uid 22791); 16 May 2011 00:14:21 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL, BAYES_00, SARE_SUB_ENC_UTF8, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 May 2011 00:14:00 +0000 Received: from eggs.gnu.org ([140.186.70.92]:45217) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QLlRg-0003Sq-4M for gcc-patches@gnu.org; Sun, 15 May 2011 20:14:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QLlRe-0003rr-W2 for gcc-patches@gnu.org; Sun, 15 May 2011 20:14:00 -0400 Received: from smtp141.iad.emailsrvr.com ([207.97.245.141]:53370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLlRe-0003rW-TI for gcc-patches@gnu.org; Sun, 15 May 2011 20:13:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id C27541A019A for ; Sun, 15 May 2011 20:13:56 -0400 (EDT) Received: from dynamic7.wm-web.iad.mlsrvr.com (dynamic7.wm-web.iad1a.rsapps.net [192.168.2.148]) by smtp24.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id AEF9A1A00E9 for ; Sun, 15 May 2011 20:13:56 -0400 (EDT) Received: from meta-innovation.com (localhost [127.0.0.1]) by dynamic7.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 8C71F153806A for ; Sun, 15 May 2011 20:13:56 -0400 (EDT) Received: by www2.webmail.us (Authenticated sender: nicola.pero@meta-innovation.com, from: nicola.pero@meta-innovation.com) with HTTP; Mon, 16 May 2011 02:13:56 +0200 (CEST) Date: Mon, 16 May 2011 02:13:56 +0200 (CEST) Subject: =?utf-8?Q?Patch=3A_New_GTY_=28=28atomic=29=29_option?= From: "Nicola Pero" To: "gcc-patches@gnu.org" MIME-Version: 1.0 X-Type: plain Message-ID: <1305504836.57384542@www2.webmail.us> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 207.97.245.141 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org This patch adds a new GTY option, "atomic", which is similar to the identical option you have with Boehm GC and which can be used with pointers to inform the GC/PCH machinery that they point to an area of memory that contains no pointers (and hence needs no scanning). The reason for adding this option is that, without it, it seems to be (surprisingly) impossible to write code that keeps a GC pointer to a plain array of C stuff such as integers. In my case, I was experimenting with hash tables that can automatically cache hash values. So I needed a plain C array to store the cached hash values, but found that it is currently unsupported by GC/PCH! :-( That is, at the moment you can't have a struct such as the following one -- struct GTY(()) my_struct { ... unsigned int * some_ints; size_t count; ... }; because gengtype rejects it with the error "field `(*x).some_ints' is pointer to unimplemented type". This patch basically implements it, but at this stage requires you to explicitly tell gengtype that the pointer is atomic (and that is safe for gengtype to ignore the memory it points to). So, the following now works as expected -- struct GTY(()) my_struct { ... unsigned int * GTY((atomic)) some_ints; size_t count; ... }; A next, nice step would be to have gengtype automatically mark as "atomic" any pointers that gengtype can safely determine point to an area of memory that never contains any pointers. But that's slightly more complicated (eg, currently gengtype makes no difference between "unsigned int" and "void", hence "unsigned int *" and "void *" would be treated the same, while you'd want the first one to be automatically marked as atomic, and the second one to generate an error as gengtype has no way to determine if it's atomic or not - unless it's explicitly marked as atomic of course), so for now I haven't implemented it; it could be a follow-up patch (even after implementing it, the explicit "atomic" option would remain useful for "void *" pointers and such like, so it's a good starting point). Btw, there are a few existing pointers in GCC that could be marked as atomic, for example the field "su" of struct function in function.h. The advantage of marking them as atomic would be a slight speedup of the GC marking by saving a function call each time one of these structs is being walked; I suspect that alone wouldn't make any visibile difference in practice, but I haven't done any profiling or benchmarking to know for sure. I have done some testing of this patch, and I want to do some more before I commit. If anyone has good ideas on how to perform throughout testing, they are welcome. :-) Ok to commit ? Thanks PS: This patch does not include support for marking root/global variables with "atomic" (neither manually nor automatically); only fields in a struct. That would be useful too, but I'm leaving it for yet another patch. 2011-05-16 Nicola Pero * gengtype.c (walk_type): Implemented "atomic" GTY option. * doc/gty.texi (GTY Options): Document "atomic" GTY option. Index: doc/gty.texi =================================================================== --- doc/gty.texi (revision 173768) +++ doc/gty.texi (working copy) @@ -383,6 +383,42 @@ could be calculated as follows: size_t size = sizeof (struct sorted_fields_type) + n * sizeof (tree); @end smallexample +@findex atomic +@item atomic + +The @code{atomic} option can only be used with pointers. It informs +the GC machinery that the memory that the pointer points to does not +contain any pointers, and hence it should be treated by the GC and PCH +machinery as an ``atomic'' block of memory that does not need to be +examined. In particular, the machinery will not scan that memory for +pointers to mark them as reachable (when marking pointers for GC) or +to relocate them (when writing a PCH file). + +The @code{atomic} option must be used with great care, because all +sorts of problem can occur if used incorrectly, that is, if the memory +the pointer points to does actually contain a pointer. + +Here is an example of how to use it: +@smallexample +struct GTY(()) my_struct @{ + int number_of_elements; + unsigned int GTY ((atomic)) * elements; +@}; +@end smallexample +In this case, @code{elements} is a pointer under GC, and the memory it +points to needs to be allocated using the Garbage Collector, and will +be freed automatically by the Garbage Collector when it is no longer +referenced. But the memory that the pointer points to is an array of +@code{unsigned int} elements, and the GC does not need, and indeed +must not, try to scan it to find pointers to mark or relocate, which +is why it is marked with the @code{atomic} option. + +Note that, currently, global variables can not be marked with +@code{atomic}; only fields of a struct can. This is a known +limitation. It would be useful to be able to mark global pointers +with @code{atomic} to make the PCH machinery aware of them so that +they are saved and restored correctly to PCH files. + @findex special @item special ("@var{name}") Index: gengtype.c =================================================================== --- gengtype.c (revision 173768) +++ gengtype.c (working copy) @@ -2386,6 +2386,7 @@ walk_type (type_p t, struct walk_type_data *d) int maybe_undef_p = 0; int use_param_num = -1; int use_params_p = 0; + int atomic_p = 0; options_p oo; const struct nested_ptr_data *nested_ptr_d = NULL; @@ -2415,6 +2416,8 @@ walk_type (type_p t, struct walk_type_data *d) ; else if (strcmp (oo->name, "skip") == 0) ; + else if (strcmp (oo->name, "atomic") == 0) + atomic_p = 1; else if (strcmp (oo->name, "default") == 0) ; else if (strcmp (oo->name, "param_is") == 0) @@ -2480,6 +2483,12 @@ walk_type (type_p t, struct walk_type_data *d) return; } + if (atomic_p && (t->kind != TYPE_POINTER)) + { + error_at_line (d->line, "field `%s' has invalid option `atomic'\n", d->val); + return; + } + switch (t->kind) { case TYPE_SCALAR: @@ -2495,6 +2504,25 @@ walk_type (type_p t, struct walk_type_data *d) break; } + /* If a pointer type is marked as "atomic", we process the + field itself, but we don't walk the data that they point to. + + There are two main cases where we walk types: to mark + pointers that are reachable, and to relocate pointers when + writing a PCH file. In both cases, an atomic pointer is + itself marked or relocated, but the memory that it points + to is left untouched. In the case of PCH, that memory will + be read/written unchanged to the PCH file. */ + if (atomic_p) + { + oprintf (d->of, "%*sif (%s != NULL) {\n", d->indent, "", d->val); + d->indent += 2; + d->process_field (t, d); + d->indent -= 2; + oprintf (d->of, "%*s}\n", d->indent, ""); + break; + } + if (!length) { if (!UNION_OR_STRUCT_P (t->u.p)