From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30435 invoked by alias); 18 Jul 2018 18:56:33 -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 30401 invoked by uid 89); 18 Jul 2018 18:56:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=occasional, sk:simark, D*simark.ca, U*simark X-HELO: gateway36.websitewelcome.com Received: from gateway36.websitewelcome.com (HELO gateway36.websitewelcome.com) (192.185.193.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Jul 2018 18:56:29 +0000 Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway36.websitewelcome.com (Postfix) with ESMTP id 75FBA400C8297 for ; Wed, 18 Jul 2018 12:58:06 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id frcEfqUSnPvAdfrcVfvX2F; Wed, 18 Jul 2018 13:56:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zw9dV71YxcBk/zuFYghswk4Kq793zWw6Lu99V8oJCAc=; b=oRNJKMQCiJBb7nDaGDj+r2HA0M 7aE+8nHyW3yc+2iJVnXDVZkRZIU6x0LrF95I3kE+HNSYI9b3n7dUaaQoSpp3WSt3tHCYMUPbaSHLU T0GT/UTgNHWQWf0DUwxOrJrcQ; Received: from 75-166-85-72.hlrn.qwest.net ([75.166.85.72]:45726 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1ffrcD-001tma-Tk; Wed, 18 Jul 2018 13:55:58 -0500 From: Tom Tromey To: Simon Marchi Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA 08/15] Remove readin and compunit_symtab fields from psymtab References: <20180510222357.27332-1-tom@tromey.com> <20180510222357.27332-9-tom@tromey.com> <5f8f38c4-8b4b-9fea-b9f2-7c69758a09c2@simark.ca> Date: Wed, 18 Jul 2018 18:56:00 -0000 In-Reply-To: <5f8f38c4-8b4b-9fea-b9f2-7c69758a09c2@simark.ca> (Simon Marchi's message of "Tue, 17 Jul 2018 23:34:00 -0400") Message-ID: <8736wg5q6b.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-07/txt/msg00564.txt.bz2 >>>>> "Simon" == Simon Marchi writes: >> In order to move psymtabs off of the objfile obstack, there must be no >> backlinks from the psymtab (or associated objects) to anything >> allocated on the objfile obstack. >> This patch removes the readin and compunit_symtab fields from psymtab >> to help achieve this goal, replacing them with per-objfile maps >> indicating which psymtabs have been read in. This split will allow >> for psymtab reuse across objfiles in the future. Simon> This LGTM, but I have two question. In the future, is the intent to also Simon> make symtabs (compunit_symtab) independent from program spaces, and Simon> shareable across objfiles, or would that not be possible? If it is Simon> possible, would the compunit_symtab pointer in psymtab re-appear, since Simon> there would now again be a single compunit_symtab for each psymtab? I think it is a good long-term goal, but not the only possible one in this area. The main downside is that it is hard to do. There's a reasonably complete to-do list here: https://sourceware.org/gdb/wiki/ObjfileSplitting Some of these steps are tricky and/or laborious. So, my thought with this second series was that perhaps gdb could get most of the benefits of the split without the full implementation. To my mind the performance issue is the major one to solve, with memory use being second. So, for instance, if gdb had this psymbol series, plus maybe incremental expansion of partial symbol tables, perhaps that would be enough. This is based in my belief that psymtab reading is the obvious spot where gdb spends its time, and that CU expansion is generally fast (but with the occasional counterexample). So maybe the full objfile splitting project will not even happen (and so the backlink would never be restored). Simon> As Pedro pointed out a few times, unordered_map is an hash map with open Simon> hashing. So we change what was previously a single pointer dereference Simon> to a lookup in a hash table, followed with a linear search in a linked Simon> list. If this map is looked up very frequently, maybe we should consider Simon> using an htab_t instead? Some profiling data would help, but it seems Simon> like psymtab_read_in_p is called quite a bit when looking up symbols... I will look into it a bit. Tom