From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11145 invoked by alias); 12 Apr 2011 11:46:46 -0000 Received: (qmail 11137 invoked by uid 22791); 12 Apr 2011 11:46:46 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f47.google.com (HELO mail-fx0-f47.google.com) (209.85.161.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 11:46:40 +0000 Received: by fxm19 with SMTP id 19so5093604fxm.20 for ; Tue, 12 Apr 2011 04:46:39 -0700 (PDT) Received: by 10.223.127.210 with SMTP id h18mr2877207fas.73.1302608799093; Tue, 12 Apr 2011 04:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.81.75 with HTTP; Tue, 12 Apr 2011 04:46:19 -0700 (PDT) In-Reply-To: References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> <4DA35F98.9060304@redhat.com> From: Laurynas Biveinis Date: Tue, 12 Apr 2011 11:46:00 -0000 Message-ID: Subject: Re: [gc-improv] Permanent vs function RTL obstack fix To: Jeff Law Cc: Steven Bosscher , gcc-patches@gcc.gnu.org, Richard Guenther , Mike Stump Content-Type: text/plain; charset=UTF-8 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/msg00857.txt.bz2 [Resending with the correct Mike's address, sorry for the spam] > So what's the plan for the case where you need to change the lifetime of > an object? Copying it. Frankly at the moment I don't how much trouble does deep copying from scratch to function entails, as mentioned in your other e-mail. ATM I am working at separating permanent from function. If it turns out to be unsurmountable, then, well, lesson learned. > What's the plan for building some kind of consistency > checking to ensure that we aren't referencing dangling pointers. I haven't thought them out in detail at this moment, but I had some ideas, very close to what Steven suggested: poisoning RTL obstacks instead of freeing/reusing. Walking existing GC memory at RTL function memory freeing time to see that no pointers point to it. The latter is virtually free even. > 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. I plan to propose merging the branch once such concerns will be adequately addressed. Personally I believe that it is possible to address them. In the case it is impossible to address them, I will propose merging very lite version of the branch that changes RTL allocation interface, keeps GC behind it, and leaves the rest for presumably brighter future. Hopefully this will not be the case. Regarding PCH: so far whenever I touch it, frankly I hate it. In the current context: the RTL output there was early-generated RTL which IMHO itself is a sign of a poor IL separation in GCC. So in that respect I believe my work is a step in a right direction, even if painful. Thanks for your feedback, -- Laurynas