From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1402 invoked by alias); 7 Jul 2009 14:26:00 -0000 Received: (qmail 1320 invoked by uid 22791); 7 Jul 2009 14:25:58 -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 14:25:49 +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 n67EPkJW016298 for ; Tue, 7 Jul 2009 10:25:46 -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 n67EPjH8003088; Tue, 7 Jul 2009 10:25:45 -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 n67EPi51008003; Tue, 7 Jul 2009 10:25:45 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 72AB73784C7; Tue, 7 Jul 2009 08:25:44 -0600 (MDT) To: gdb-patches@sourceware.org Subject: Re: RFC: reference counting for value References: <20090707014914.GA30559@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey Date: Tue, 07 Jul 2009 14:26:00 -0000 In-Reply-To: <20090707014914.GA30559@caradoc.them.org> (Daniel Jacobowitz's message of "Mon\, 6 Jul 2009 21\:49\:14 -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/msg00195.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> I am trying to resurrect an old patch of Vladimir's, which gives Daniel> bitfield values a parent pointer. We fetch the parent once, instead Daniel> of once per bitfield. That raised an interesting question: Tom> + /* The reference count. A value that is still on the `all_values' Tom> + list will have a reference count of 0. A call to `release_value' Tom> + will increment the reference count (and remove the value from the Tom> + list, the first time). A call to `value_free' will decrement the Tom> + reference count, and will free the value when there are no more Tom> + references. */ Tom> + int refcount; Tom> + Tom> /* Register number if the value is from a register. */ Tom> short regnum; Tom> Daniel> If we release_value the parent every time we create a child, and Daniel> value_free it every time we collect a child, the parent will be freed Daniel> as soon as its last child is. This is a change in the value behavior, Daniel> because otherwise it would hang around until value_free_to_mark or Daniel> free_all_values. Daniel> Is this going to bite us? Yes, I think so. Daniel> We could, instead, record release_value Daniel> references separately from parent references and leave the value on Daniel> the chain. But if it doesn't matter, I'd rather not. Another idea I've been kicking around a bit is to also reference count the contents. This would solve this particular problem without needing a bitfield->parent reference, as the two would just share some structure. My reasons for considering this change are, first, it would be more memory-efficient in some value_copy cases; and, second, I think it would let us merge val_print and value_print. I was also thinking that it would help with properly implementing unavailable pieces via DW_OP_piece (I thought: removing val_print would make it simpler to handle all this via the value API, and structure sharing seemed necessary for removing val_print), but now I'm not as sure. It is probably just as easy to pass a "valid" bitmap through the val_print hierarchy. BTW, I have not checked in the value reference counting patch. I plan to it until I've dealt with the python/varojb regression it introduces. Tom