From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31670 invoked by alias); 12 Apr 2011 06:34:02 -0000 Received: (qmail 31654 invoked by uid 22791); 12 Apr 2011 06:34:01 -0000 X-SWARE-Spam-Status: No, hits=-2.2 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-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 06:33:57 +0000 Received: by yxn22 with SMTP id 22so3630346yxn.20 for ; Mon, 11 Apr 2011 23:33:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.102.5 with SMTP id z5mr186843anb.93.1302590036296; Mon, 11 Apr 2011 23:33:56 -0700 (PDT) Received: by 10.100.214.4 with HTTP; Mon, 11 Apr 2011 23:33:56 -0700 (PDT) In-Reply-To: <4DA3BEEA.10608@redhat.com> References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> <4DA35E74.1020506@redhat.com> <6E9E9711-46D0-4B15-BB5D-15253EE00753@comcast.net> <4DA3BEEA.10608@redhat.com> Date: Tue, 12 Apr 2011 06:34:00 -0000 Message-ID: Subject: Re: [gc-improv] Permanent vs function RTL obstack fix From: Steven Bosscher To: Jeff Law Cc: Mike Stump , Laurynas Biveinis , gcc-patches Patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00833.txt.bz2 On Tue, Apr 12, 2011 at 4:54 AM, Jeff Law wrote: > On 04/11/11 18:21, Mike Stump wrote: >> On Apr 11, 2011, at 1:03 PM, Jeff Law wrote: >>> The obvious solution is you copy the object, but then you have to be >>> able to distinguish within the object, what fields point to other >>> temporary objects vs permanent objects so that you can copy the >>> referenced temporary objects, but not the permanent objects (other parts >>> of the compiler may expect those permanent objects to be unique/shared). >>> =A0 Not fun, not at all fun. =A0Been there, done that. >> >> And then someone tells you that you can't copy... =A0Usually a nasty bug= report much later. =A0So the choice is then, not solve a problem, or make = everything permanent or add GC (back). =A0:-) =A0Been there, done that too. > Right. =A0Hence the old hack to mark the temporary obstacks and make them > permanent (wasting an enormous amount of space in the process). =A0I don't > recall the name of that function, but it certainly made me barf. > > And yes, I remember all too well the problems with deep copying having > written one of the earliest tree deep copy routines to support > - -fcombine-statics . =A0It was the source of more problems than I could > ever count -- all related to objects allocated to different obstacks > hanging off a single tree node or objects of two different types being > stored into the same field within tree nodes. =A0That was circa 1992/1993. > > > These were the kind of problems that ultimately led to the GC system we > have today. =A0There are clearly things that can be better handled with > different allocation models and I'll support moving to better models > where it makes sense. =A0Where it doesn't, obviously I won't support it. I am unsure how to interpret that last sentence. Do you currently believe that the approach of 2 or 3 obstacks for RTL is a better model that makes sense, or not? I think all these comments from you "old guys" ;-) are more discouraging than fair. What Laurynas and Bernd have done, is nothing like the old obstacks of GCC2. I am also a bit surprised that all these fears only come up now that someone actually tries to do what Zack already suggested in 2003, around the time that unit-at-a-time compilation became the default mode. Anyway, please do give this idea a chance at least. There is a big difference between the pre-GC obstacks and what Laurynas is now trying (not just in terms of memory management, but in the entire compilation process!) and apart from the name "obstacks" this idea and the pre-GC memory management in GCC have nothing in common. Ciao! Steven