From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31646 invoked by alias); 17 Aug 2010 23:26:33 -0000 Received: (qmail 31638 invoked by uid 22791); 17 Aug 2010 23:26:33 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Aug 2010 23:26:23 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7HNQM93000944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Aug 2010 19:26:22 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7HNQLdI006321; Tue, 17 Aug 2010 19:26:21 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o7HNQKLG020437; Tue, 17 Aug 2010 19:26:21 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id A3D89378196; Tue, 17 Aug 2010 17:26:20 -0600 (MDT) From: Tom Tromey To: sami wagiaalla Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Use custom hash function with bcache References: <4C6946E1.6000709@redhat.com> Date: Tue, 17 Aug 2010 23:26:00 -0000 In-Reply-To: <4C6946E1.6000709@redhat.com> (sami wagiaalla's message of "Mon, 16 Aug 2010 10:10:41 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2010-08/txt/msg00283.txt.bz2 >>>>> "Sami" == sami wagiaalla writes: Sami> This patch enables the use of custom hash and comparison functions Sami> when adding elements to a bcache. The patch also introduces hash and Sami> comparison functions which take into consideration only the relevant Sami> properties of the psymbol. I don't understand how this approach can work as-is. The bcache interns objects. It doesn't know anything about their semantics, just their size. This patch means that a given bcache could include two objects of the same size that have different hash and comparison functions. So, it seems like some kind of clash could (in theory) result. This is very bad if one object is mutable and the other is not. I think it would be safer to either: 1. Make the hash and comparison functions part of the bcache itself, set only when the bcache is allocated, then audit all uses of this particular bcache to make sure that only psymtabs are added to it (this could be done by introducing a new type, so that invalid uses are compile-time errors), or 2. Do psymtab interning in an htab_t. I suspect this will have worse overhead, but I really don't know. I think you can make the psym hash and comparison functions a bit simpler by just skipping the pointer-sized lang-specific hole. This is maybe more future-proof as well. Tom