From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9394 invoked by alias); 23 Jan 2007 12:12:06 -0000 Received: (qmail 9383 invoked by uid 22791); 23 Jan 2007 12:12:05 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 23 Jan 2007 12:12:01 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H9KV9-0000Be-UU; Tue, 23 Jan 2007 07:11:48 -0500 Date: Tue, 23 Jan 2007 12:12:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: [PATCH] MI: Free values when updating Message-ID: <20070123121147.GA32010@nevyn.them.org> Mail-Followup-To: Nick Roberts , Vladimir Prus , gdb-patches@sources.redhat.com References: <17845.48393.877158.536969@kahikatea.snap.net.nz> <17845.52624.949137.508231@kahikatea.snap.net.nz> <200701231215.08114.ghost@cs.msu.su> <17845.60212.898642.763807@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17845.60212.898642.763807@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) 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: 2007-01/txt/msg00467.txt.bz2 On Wed, Jan 24, 2007 at 12:02:12AM +1300, Nick Roberts wrote: > > > it's just that this patch stops calling it at other times > > > when it's needed. Without any change, do enable timings (if you have that > > > patch), create a variable object of a large array and all its children then > > > repeatedly do "-var-update *". It should take longer and longer to execute. > > > > Why? Is it because the memory consumption of gdb grows, or because the list > > of released values grows without ever being cleared, or for some other > > reason? > > The latter, I think. Except that there isn't a list of released values. So what is GDB doing that is taking longer and longer? The call to release_value does a linear walk over all non-released values. So if we have a lot of things which aren't being released, then your patch which calls free_all_values is probably the right thing to do - that should clean it up. > > - if (gdb_evaluate_expression (var->root->exp, &new_val)) > > - { > > - release_value (new_val); > > - } > > - > > + gdb_evaluate_expression (var->root->exp, &new_val); > > return new_val; > > } > > I think if you also remove the (3) calls to release_value in c_value_of_child > and cplus_value_of_child this is equivalent to my change (and more tidy). No, those are different. They come from things like the call to gdb_value_ind in c_describe_child. That creates a new value, which is returned to the caller (the MI front end, to be printed and later released). It's the ones in c_value_of_root which matter, because we save them in the varobj. You're probably right about the increasing time though - releasing something already released will be slow. I wonder if we should make that an internal error somehow. -- Daniel Jacobowitz CodeSourcery