From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17252 invoked by alias); 16 Nov 2017 23:26:54 -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 17239 invoked by uid 89); 16 Nov 2017 23:26:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=leftover X-HELO: gateway31.websitewelcome.com Received: from gateway31.websitewelcome.com (HELO gateway31.websitewelcome.com) (192.185.144.218) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Nov 2017 23:26:50 +0000 Received: from cm15.websitewelcome.com (cm15.websitewelcome.com [100.42.49.9]) by gateway31.websitewelcome.com (Postfix) with ESMTP id CAACFE2932 for ; Thu, 16 Nov 2017 17:26:48 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id FTYWeMCGp5b6TFTYWeYa6d; Thu, 16 Nov 2017 17:26:48 -0600 Received: from 71-218-90-63.hlrn.qwest.net ([71.218.90.63]:52138 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eFTYW-002yd0-HY; Thu, 16 Nov 2017 17:26:48 -0600 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA] Handle dereferencing Rust trait objects References: <20171115212403.8639-1-tom@tromey.com> Date: Thu, 16 Nov 2017 23:26:00 -0000 In-Reply-To: (Pedro Alves's message of "Thu, 16 Nov 2017 16:34:59 +0000") Message-ID: <87bmk19554.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1eFTYW-002yd0-HY X-Source-Sender: 71-218-90-63.hlrn.qwest.net (pokyo) [71.218.90.63]:52138 X-Source-Auth: tom+tromey.com X-Email-Count: 4 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2017-11/txt/msg00329.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> std::unordered_map + pointers (or really small objects) makes me Pedro> cry. :-) That has nasty memory overhead/footprint, with Pedro> unordered_map being a node container... I could do something else. A vector of pairs, sorted by address; or an htab_t. Pedro> Can you say something about the number of elements that usually Pedro> ends up in this map in some reasonably sized Rust-using app (Firefox?)? I will look at this tomorrow. Pedro> I'm assuming that you end up with many contiguous symbols pointing to Pedro> the same psymtab? Would an addrmap (addrmap.h/c) be a good fit here? Pedro> Maybe not if we don't have the size of the psymbols handy when Pedro> we build this... :-/ Yes, the size isn't known, because psymtab reading doesn't really look at the types. Maybe an addrmap wouldn't be too bad though. Perhaps I'll try a couple of ideas and try to see what uses the least memory. Pedro> This reinterpret_cast looks like a big hammer here. Why not Pedro> static_cast? I changed it. Not sure why I had that .. maybe leftover from before I used derivation. Pedro> A symbol can't be both is_cplus_template_function and is_rust_vtable, Pedro> I think it'd be better long term if we merged the tag to a single Pedro> enum bitfield (with two bits). But it's not that big a deal and Pedro> can always be done later. I can do this. Tom