From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25020 invoked by alias); 2 May 2008 00:58:00 -0000 Received: (qmail 25006 invoked by uid 22791); 2 May 2008 00:57:58 -0000 X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 May 2008 00:57:37 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m420vUIK014247; Thu, 1 May 2008 19:57:30 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 19:57:30 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH:MI] Return a subset of a variable object's children Date: Fri, 02 May 2008 00:58:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04E1BD13@ecamlmw720.eamcs.ericsson.se> References: <6D19CA8D71C89C43A057926FE0D4ADAA042910B6@ecamlmw720.eamcs.ericsson.se> <200805011954.31277.vladimir@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA04E1BD10@ecamlmw720.eamcs.ericsson.se> <200805012239.59601.vladimir@codesourcery.com> From: "Marc Khouzam" To: "Vladimir Prus" Cc: "Nick Roberts" , 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: 2008-05/txt/msg00055.txt.bz2 > > DSF-GDB tries to be as efficient as possible by avoiding request that go > > to the backend. Therefore, although a varObj is no longer being showed, > > we want to keep it around in case it will be showed again. Effectively, > > we are caching. And our cache size is 1000 varObj. >=20 > What does it mean "no longer being showed". If you have a variables tree, > and some variable is in the tree, but is not visible on the screen right = now, > there's no need whatsoever to delete the variable object for that variabl= e. Ok, I had misunderstood your previous explanation on when to delete varObj. When I say "not shown" I mean that it is not visible on the screen right no= w. So in DSF, we don't delete varObj that are not on the screen, but keep them in what I described earlier as a cache. > If that variable is huge structure, then updating it (inside GDB) on each > step, can take some time, especially on a slow remote target. But, I think > you send -var-update once per each visible variable, so this is not an is= sue > for you. > If a variable is deleted from variables tree (because you left the scope > where that variable is defined), then you should delete variable object. > There's no reliable way to detect that exactly same variable is in scope > again and must be shown, so no reuse is possible. We chose a more passive approach. The frontend relies entirely on GDB to=20 know if a varObj has gone out-of-scope. Since GDB reports this only if the varObj is given the var-update command, we don't get to know it very often, because we only use the var-update command for varObj we want to know the value of. I believe an example is in order :-) Say you have local variable bar in method foo(). We create a varObj for bar. Once we return from foo(), there is no longer a local variable bar, so we don't send a -var-update for it, which in turn means we don't realize that it is out-of-scope and we don't delete it. What this implies in the end is that we only delete a varObj if our cache is full. The only exception to this rule is when the expression of a=20 variable object is re-used which will trigger a var-update, which will show that the old varObj is out-of-scope (so we create a new one.) (if after returning from foo(), there is another local variable bar) > Honestly, except for the fact that -var-update reads target memory, I'm s= ure > that GDB can create more variable objects that SWT can create TreeItems := -) That is exactly what I wanted to know. I won't worry so much about having too many varObj :-) > > > There are natural scalability bounds in the UI -- if there are no > > > arrays involved, and you try to show 1000 items (backed by 1000 varia= ble objects), > > > the UI is already useless. GDB is not the problem here. > >=20 > > Right, but for us the 1000 varObj are not meant to all be displayed at = once > > but are a caching system. >=20 > I'm still not sure what you mean -- you mean that a variable object is no= t shown > in any widget, but only is stored in the cache? What is the key of the ca= che? Ah yes, the key of the cache. That gave me a big headache :-) It is a object containing: the expression for the varObj, the thread it is = part of, and the frame level. If the same expression (variable name) is used in the same thread at the sa= me frame level, then we first think it is the same varObj and we use -var-update; we= then get an out-of-scope and we delete the old varObj and create a new one. > > > What I don't see as a valid use case is one where: > > >=20 > > > 1. The size of array is too large to keep all varobj always created. > >=20 > > I'm not sure what you mean here. Before Nick's patch, issuing -var-lis= t-children > > on a large array would create a lot of varObjs. In our case, it would = have > > filled up our varObj cache, although we would only be showing very few = of the > > array elements. >=20 > Well, then, the problem is in *your* code :-) If GDB has no problem creat= ing > variables objects for all children, but your cache fills up, then you hav= e wrong > size of a cache. That may be true. But it would be nice to have the freedom to control this ourselves, and therefore, not to be forced to create a very large amount of children; which is where Nick's patch comes in, or the "slicing of array= s", our the DSF solution of not listing the children of arrays. > > > 2. User would like to just scroll though all the array items, without > > > clear intentions. > >=20 > > This is probably not a valid use case... although user behavior, even w= hen dumb :-) > > should not break the frontend. >=20 > Yes, this is my "Oops" use case -- we should create some reasonable numbe= r of children > initially, and incrementally fetch more per user request, thereby giving = the user a > chance to stop :-) Exactly. >=20 > > But you got me thinking now... Maybe var-create using with an array sli= ce is all we > > need for dealing with a large array? >=20 > I don't know. It means that if you want to get more children, you have to= delete variable > object, and create new one and list children. Not really. I believe what CDT does is that each array bigger than 100 is = divided into groups of 100 children. So, there is a new varObj for each group of 100; t= he "slice" is not increased but instead, a new "slice" is created. Marc