From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15440 invoked by alias); 20 Jul 2009 13:21:10 -0000 Received: (qmail 15431 invoked by uid 22791); 20 Jul 2009 13:21:09 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-qy0-f198.google.com (HELO mail-qy0-f198.google.com) (209.85.221.198) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jul 2009 13:21:03 +0000 Received: by qyk36 with SMTP id 36so1946489qyk.12 for ; Mon, 20 Jul 2009 06:21:01 -0700 (PDT) Received: by 10.224.20.15 with SMTP id d15mr2628536qab.140.1248096060996; Mon, 20 Jul 2009 06:21:00 -0700 (PDT) Received: from hotblack.localnet ([189.4.46.16]) by mx.google.com with ESMTPS id 5sm7027095qwg.45.2009.07.20.06.20.59 (version=SSLv3 cipher=RC4-MD5); Mon, 20 Jul 2009 06:20:59 -0700 (PDT) From: Thiago Jung Bauermann To: gdb-patches@sourceware.org Subject: Re: Value reference counting Date: Mon, 20 Jul 2009 13:30:00 -0000 User-Agent: KMail/1.11.4 (Linux/2.6.30-1-amd64; KDE/4.2.4; x86_64; ; ) Cc: Daniel Jacobowitz , Tom Tromey , Vladimir Prus References: <20090717184152.GA6863@caradoc.them.org> <20090717190418.GA9041@caradoc.them.org> In-Reply-To: <20090717190418.GA9041@caradoc.them.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907201022.19758.thiago.bauermann@gmail.com> X-IsSubscribed: yes 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/msg00472.txt.bz2 Em Sexta-feira 17 Julho 2009 16:04:18 Daniel Jacobowitz escreveu: > On Fri, Jul 17, 2009 at 12:53:52PM -0600, Tom Tromey wrote: > > 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? > > I had a good reason this would leak values for watchpoints, but now I > can't get it to work out. Still, it makes me nervous. Watchpoints hold their own references to values. Other than that, IMHO if watchpoint code causes values to be leaked, that is a bug, not a special feature which should be respected... WDYT? > free_all_values can have a very long interval. But it looks like > breakpoint commands always run it, so not unbounded user behavior. > What about breakpoint conditions? Is anything released and free'd > during a condition check going to linger until we stop? I don't like the idea of having the GC being ran at unpredictably long intervals. Aren't we aiming at debugging big fat apps with big insane debugging sessions afterall? -- []'s Thiago Jung Bauermann