From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8600 invoked by alias); 7 Jul 2009 17:03:26 -0000 Received: (qmail 8411 invoked by uid 22791); 7 Jul 2009 17:03:25 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Jul 2009 17:03:17 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n67H3FRl031570 for ; Tue, 7 Jul 2009 13:03:15 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n67H3Ea4020967; Tue, 7 Jul 2009 13:03:14 -0400 Received: from opsy.redhat.com (vpn-225-86.phx2.redhat.com [10.3.225.86]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n67H3Dwx008081; Tue, 7 Jul 2009 13:03:13 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 5CDF43784C7; Tue, 7 Jul 2009 11:03:12 -0600 (MDT) To: gdb-patches@sourceware.org Subject: Re: RFC: reference counting for value References: <20090707014914.GA30559@caradoc.them.org> <20090707145930.GA18388@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey Date: Tue, 07 Jul 2009 17:03:00 -0000 In-Reply-To: <20090707145930.GA18388@caradoc.them.org> (Daniel Jacobowitz's message of "Tue\, 7 Jul 2009 10\:59\:30 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.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: 2009-07/txt/msg00205.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Tom> Another idea I've been kicking around a bit is to also reference count Tom> the contents. This would solve this particular problem without Tom> needing a bitfield->parent reference, as the two would just share some Tom> structure. Daniel> Would it? We need to be able to fetch the contents in response to a Daniel> request from the bitfield, so everything needed to unlazy would Daniel> have to be in the shared structure; I guess that's address and length, Daniel> here. Also lval type. Would we have to duplicate these in the value Daniel> and the shared contents? I hadn't been thinking about the lazy case, but after thinking about it a bit, it still doesn't seem so bad to me. Yeah, you'd have to push this stuff into the contents (lval type? I dunno). Something like struct value_contents { enum lval_type lval : 8; unsigned int lazy : 1; unsigned int refcount : 23; // or whatever CORE_ADDR address; gdb_byte contents[1]; // should perhaps use the aligner stuff from before }; struct value { ... struct value_contents *contents; } value::offset would continue to be an offset into the contents; when doing something like a field reference, we'd make a new reference to 'contents' and set the offset in the new value appropriately. For unavailable pieces, we'd also stick the validity bitmap (or something) into value_contents. Daniel> If two values have a shared contents structure, I'm not sure Daniel> what point there is having them different value structures in Daniel> the first place. To act as a content cache, so we can avoid duplicating large contents when copying (and slicing, etc) values and avoid (as in your case) redundant fetches. Some other caching approach may work just as well. That's how I understand the parent-pointer idea as well -- a specialized cache. I'm not really wedded to this. I'm not even sure I want to get rid of val_print -- I find it to be a strange wart, but it would probably be a lot of work for not much benefit (unless it really does simplify the unavailable piece thing). Tom