From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13505 invoked by alias); 31 May 2013 16:15:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 13495 invoked by uid 89); 31 May 2013 16:15:03 -0000 X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 31 May 2013 16:15:02 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4VGExvT019419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 May 2013 12:14:59 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r4VGEvhx021990; Fri, 31 May 2013 12:14:58 -0400 Message-ID: <51A8CC81.9070509@redhat.com> Date: Fri, 31 May 2013 16:15:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Tom Tromey CC: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: RFC: introduce scoped cleanups References: <87li7ohtiu.fsf@fleche.redhat.com> <87ppw8qlgl.fsf@fleche.redhat.com> <20130531061135.GA12363@adacore.com> <87obbrp2hg.fsf@fleche.redhat.com> In-Reply-To: <87obbrp2hg.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg01112.txt.bz2 On 05/31/2013 04:56 PM, Tom Tromey wrote: >>> Pedro said he was interested in general stack-based allocation of >>> cleanups, so I implemented that, following his plan. > > Joel> Is this purely for performance? > > Yeah, I think so. Yeah, like, Tom, I've occasionally found myself sometimes considering avoiding cleanups, avoiding the heap allocations, in cases performance may matter. Clearly we're not alone, as evidenced from several of Tom's patches exposing spots where we were avoiding having a "master" cleanup, some times using tricky conditionals. I had thought of this stack cleanups scheme before, but never actually went through with it. Seeing Tom's scope cleanups were already stack based and most of the way there, made me feel that it'd be a pity to be able to have stack-based cleanups, but then as soon as you need a real cleanup that does actual cleanup (as opposed to null_cleanup), you still need to get back to install a heap cleanup anyway. -- Pedro Alves