From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24252 invoked by alias); 12 Apr 2011 15:02:49 -0000 Received: (qmail 24245 invoked by uid 22791); 12 Apr 2011 15:02:47 -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; Tue, 12 Apr 2011 15:02:34 +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 p3CF2Wtc024356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 11:02:32 -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 p3CF2VW6019531; Tue, 12 Apr 2011 11:02:32 -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 p3CF2Teo023691; Tue, 12 Apr 2011 11:02:30 -0400 Message-ID: <4DA46985.3040405@redhat.com> Date: Tue, 12 Apr 2011 15:02: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: Steven Bosscher CC: Jakub Jelinek , Mike Stump , Laurynas Biveinis , gcc-patches Patches Subject: Re: [gc-improv] Permanent vs function RTL obstack fix References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> <4DA35E74.1020506@redhat.com> <6E9E9711-46D0-4B15-BB5D-15253EE00753@comcast.net> <4DA3BEEA.10608@redhat.com> <20110412070107.GB17079@tyan-ft48-01.lab.bos.redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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/msg00899.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/11 02:45, Steven Bosscher wrote: > On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek wrote: >> On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote: >>> I think all these comments from you "old guys" ;-) are more >>> discouraging than fair. What Laurynas and Bernd have done, is nothing >> >> It is IMHO completely fair to point that the risks this brings in >> a huge maintainance nightmare are very high. > > And IM-equally-HO it is completely unfair to talk about risks in any > situation where there is nothing yet to talk about! Give it a chance > and wait for something that's more than just an idea, and then assess > the risks based on an implementation. Given that we've already got a goodly amount of experience with obstack and GC based mechanisms for allocation, I think it is completely fair and wise to discuss the known risk/reward for both. > > Or just say "this won't fly" now so that people who would like to work > on this can turn their attention to something else. Also fine. Really. I have serious concerns about reverting to obstacks as our main memory allocation approach for tree & rtl data. However, I also realize that there are objects where obstacks make sense and I realize some of those objects may currently be hanging off tree or RTL structures. With that in mind, I'm all for a critical examination of our data structures, their lifetimes and what allocation model works best. From that I would expect that we'll find some cases where an obstack model works better and the structures will move to that model. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNpGmEAAoJEBRtltQi2kC7cjUIALtwCRbcsxABIx6xtWlZIHRy vPfB8pc6u+IhIrbu/T2qZjUoP6bq5UQIgCPIy3o7qSgJ5Qd8NvYJQ5nMHMyPZvX2 MDzyTJcMB1OUsoZhgVwTdZoL1aSp3ARopruDM2DNc9zo8DXP5YFcn2w6bXaASjr5 jENRoiqTe6hLgJXQZT7QQObusR6gM4Off78Hs/vGlaOmeXMSONfMTxms1ya0ROQe h+YyXpQuLsUDdIO9wSHfeD0/73er8fLYqlcJ77GPUDK907oVtr4bKUWOirwX9QL2 vRwMur93cVjPvHuNUPZdNxsrpozJH+G/iAIPJVa3K+AYXBvvzWtSpDHb4ttvy48= =pN2J -----END PGP SIGNATURE-----