From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30052 invoked by alias); 17 Jul 2009 18:56:05 -0000 Received: (qmail 30043 invoked by uid 22791); 17 Jul 2009 18:56:04 -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; Fri, 17 Jul 2009 18:55:56 +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 n6HIrsLo019044; Fri, 17 Jul 2009 14:53:54 -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 n6HIrrXj027470; Fri, 17 Jul 2009 14:53:53 -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 n6HIrqsQ016592; Fri, 17 Jul 2009 14:53:53 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 37914508006; Fri, 17 Jul 2009 12:53:52 -0600 (MDT) To: gdb-patches@sourceware.org Cc: Vladimir Prus Subject: Re: Value reference counting References: <20090717184152.GA6863@caradoc.them.org> From: Tom Tromey Reply-To: tromey@redhat.com Date: Fri, 17 Jul 2009 19:04:00 -0000 In-Reply-To: <20090717184152.GA6863@caradoc.them.org> (Daniel Jacobowitz's message of "Fri\, 17 Jul 2009 14\:41\:53 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (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/msg00435.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> This patch, based on an old patch from Vladimir, implements Daniel> reference counting for values. Tom, this is the approach I Daniel> discussed with you on IRC: instead of treating the value chain Daniel> as a normal reference and using release_value to take Daniel> references, this separates the value chain (which is boolean; a Daniel> value is either on it or not) from references (which are Daniel> counted). Daniel> So you take a reference with value_incref. release_value Daniel> transforms the value chain's reference into a normal reference. Daniel> That's an entirely theoretical operation, by which I mean Daniel> release_value doesn't have to do anything special. Daniel> Does this look OK? Tom, will it work for the Python code? This will work fine for Python. Also, I think that this model is clearer than what I did. It seems to me that at this point, release_value is doing a walk of a linked list for no particular benefit. Suppose we deleted release_value and replaced all calls to it with calls to value_incref? This might result in some values living slightly longer than they otherwise would have (they will live until free_all_values, whereas currently they will be deleted at value_free time, which might or might not be sooner). The only thing I could think of is whether this would affect watchpoint operation, since IIUC the watchpoint code examines all_values. But, if this problem exists, it could be worked around by examining the reference count of values on the chain. What do you think? Tom