From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75527 invoked by alias); 26 Apr 2018 17:42:35 -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 75486 invoked by uid 89); 26 Apr 2018 17:42:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=resizing, HTo:D*ca, ugly X-HELO: gateway20.websitewelcome.com Received: from gateway20.websitewelcome.com (HELO gateway20.websitewelcome.com) (192.185.48.38) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Apr 2018 17:42:29 +0000 Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 13CC9400DED4D for ; Thu, 26 Apr 2018 12:42:28 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id BkuZfwzzoQUwqBkuZfhfj9; Thu, 26 Apr 2018 12:42:28 -0500 X-Authority-Reason: nr=8 Received: from 97-122-176-117.hlrn.qwest.net ([97.122.176.117]:58058 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fBkuZ-001opf-Mr; Thu, 26 Apr 2018 12:42:27 -0500 From: Tom Tromey To: Simon Marchi Cc: Tom Tromey , Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] Introduce obstack_new, poison other "typed" obstack functions References: <1524685183-5553-1-git-send-email-simon.marchi@ericsson.com> <87sh7i7w2i.fsf@tromey.com> <129280589d474492d52e33e7997b47a7@polymtl.ca> Date: Thu, 26 Apr 2018 17:42:00 -0000 In-Reply-To: <129280589d474492d52e33e7997b47a7@polymtl.ca> (Simon Marchi's message of "Wed, 25 Apr 2018 22:58:03 -0400") Message-ID: <87lgd97tkt.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1fBkuZ-001opf-Mr X-Source-Sender: 97-122-176-117.hlrn.qwest.net (pokyo) [97.122.176.117]:58058 X-Source-Auth: tom+tromey.com X-Email-Count: 3 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-04/txt/msg00536.txt.bz2 >>>>> "Simon" == Simon Marchi writes: >> foo *f = new (obstack) foo (); Simon> I thought about this. The downside I see is that it forces new to Simon> allocate on an obstack. What if you want to use the standard new for Simon> the same type in another context? Maybe this doesn't happen in Simon> practice though. Good point. We could have another mixin to provide a second operator new, but that seems sort of ugly. Simon> So if that was the main reason an obstack is used, you Simon> might as well reconsider using an obstack at all [1]. But if the Simon> obstack is used for the more efficient memory allocation, then it Simon> would still make sense to use an obstack and track the objects Simon> separately so that they can be destroyed properly. What we need is Simon> (not sure this is realistic): everywhere we allocate an object on an Simon> obstack and don't keep track of it for further destruction, have a Simon> static_assert there that the type should be trivially destructible. Yeah. And I'm not sure if this is doable either. Maybe if we removed allocate_on_obstack and switched completely to your obstack_new, and then made it static_assert is_trivially_destructible. Simon> Or maybe there are better C++ ways of getting the same advantages as Simon> with an obstack (efficient allocation for a bunch of objects Simon> allocated/freed at the same time, data locality)? I'm not totally sure that obstacks are so great. For example see https://sourceware.org/bugzilla/show_bug.cgi?id=17143 In the past I think many times, something was put on the objfile obstack simply because it was convenient. For example I know there were cases where this was done with hash tables (even though hash resizing means leaking storage) just because it was simpler than trying to find the correct spot to clean up. This aspect is certainly something we can do more easily now with C++ -- just make the members clean up after themselves. Tom