From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12881 invoked by alias); 11 Apr 2011 20:08:01 -0000 Received: (qmail 12872 invoked by uid 22791); 11 Apr 2011 20:08:00 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Apr 2011 20:07:55 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3BK7tUE023418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Apr 2011 16:07:55 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p3BK7sep017325; Mon, 11 Apr 2011 16:07:54 -0400 Received: from [10.3.113.84] (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p3BK7rS2020203; Mon, 11 Apr 2011 16:07:53 -0400 Message-ID: <4DA35F98.9060304@redhat.com> Date: Mon, 11 Apr 2011 20:08:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Laurynas Biveinis CC: Steven Bosscher , gcc-patches@gcc.gnu.org, Richard Guenther Subject: Re: [gc-improv] Permanent vs function RTL obstack fix References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg00800.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/10/11 12:22, Laurynas Biveinis wrote: > > It is certainly true that moving away from GC will make some kinds of > bugs possible again, but I hope that not enough to be an unmanageable > concern. It's definitely a huge concern. More for tree objects than RTL objects though. The RTL object lifetimes seem to be clear in most of the > instances and so far I am going with only two of them: permanent and > function. After the initial conversion is done, I don't expect much > trouble for any new RTL allocations introduced to be decided which > memory area they belong to. > > Adding a third area, e.g. per-TU, of course would complicate this, but > I still believe this is manageable. So what's the plan for the case where you need to change the lifetime of an object? What's the plan for building some kind of consistency checking to ensure that we aren't referencing dangling pointers. I ask these questions because they were a serious source of problems in the past and any significant revamping of memory management needs to have a reasonable story for how to deal with them, else we're taking a rather significant step backwards. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNo1+YAAoJEBRtltQi2kC7LeMH/2pxPMnlJAsjiwHApURV/sxX 5XyGBvawPs1W6zobBRUeOhIrfn8hSm6P2QywZvj7EpfTbiD/aKdVXz8zBOC2J1IG 69TDQwXY4YhqEW5WxTsBK6YAoFTALebZe6dbLRuN5795X+d5rSZmlyiX/GgICB7M 2iMqqkH6kv9wO2k6pfeN6k+hIHZmpVHRg3KeADTWvO5+3FKkVWFizA3LHhPf/pDM 7sG5o6CB8AI7PBNgh6A7xNs045NexIhEdkQ/R7jQNpySk3XHpfOPhjKh135hWwnw 6UoR8xqned5nr1sj6n07i+hSvYDLT6Izm68ZnFe5E09lPemVe4rZnO6Sb/+fhOA= =gD9u -----END PGP SIGNATURE-----