From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8015 invoked by alias); 26 Apr 2018 02:58:14 -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 8000 invoked by uid 89); 26 Apr 2018 02:58:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Yao X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Apr 2018 02:58:12 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w3Q2w5ZD027691 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 25 Apr 2018 22:58:10 -0400 Received: by simark.ca (Postfix, from userid 112) id C076F1EF61; Wed, 25 Apr 2018 22:58:05 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 550F21E47D; Wed, 25 Apr 2018 22:58:03 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 26 Apr 2018 02:58:00 -0000 From: Simon Marchi To: Tom Tromey Cc: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] Introduce obstack_new, poison other "typed" obstack functions In-Reply-To: <87sh7i7w2i.fsf@tromey.com> References: <1524685183-5553-1-git-send-email-simon.marchi@ericsson.com> <87sh7i7w2i.fsf@tromey.com> Message-ID: <129280589d474492d52e33e7997b47a7@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 26 Apr 2018 02:58:05 +0000 X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00531.txt.bz2 Hi Tom, Thanks for taking a look. On 2018-04-25 18:36, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > > Simon> This patch introduces a utility to make this pattern simpler: > Simon> foo *f = obstack_new (); > > What about just having those types that can use this inherit from > allocate_on_obstack? Then you can write: > > foo *f = new (obstack) foo (); I thought about this. The downside I see is that it forces new to allocate on an obstack. What if you want to use the standard new for the same type in another context? Maybe this doesn't happen in practice though. > It would be nice if we could have a global operator new that does this, > but I don't think it is possible to have one that is limited to > is_trivially_constructible classes. That goes beyond my C++ knowledge. > Maybe is_trivially_destructible is also needed somehow since an obstack > isn't going to run those destructors. Not sure how to manage this > either, right now allocate_on_obstack just assumes you know what you're > up to. I remember you having some back and forth with Yao about this. Here's my take on it. It is possible to allocate objects that need to be destroyed on obstacks, the important thing is to call the destructor manually at some point before the obstack is freed. It's done for mapped_index right now, for example. You just can't allocate such an object on an obstack and forget about it, assuming it will be freed by magic (it's just like when you "new" something, you have to keep track of it to destroy it at some point). When doing this, you obviously lose one nice feature of the obstack, not having to care about deallocation. So if that was the main reason an obstack is used, you might as well reconsider using an obstack at all [1]. But if the obstack is used for the more efficient memory allocation, then it would still make sense to use an obstack and track the objects separately so that they can be destroyed properly. What we need is (not sure this is realistic): everywhere we allocate an object on an obstack and don't keep track of it for further destruction, have a static_assert there that the type should be trivially destructible. If you happen to make said type non trivially destructible, you'll get an error and realize "oh right, the objects created here are never destroyed". Or maybe there are better C++ ways of getting the same advantages as with an obstack (efficient allocation for a bunch of objects allocated/freed at the same time, data locality)? [1] For example, is there a reason why mapped_index is allocated on the objfile obstack, and not newed just like mapped_debug_names? Simon