RE: [PATCH:MI] Return a subset of a variable object's children

["Marc Khouzam" <marc dot khouzam at ericsson dot com>]

> > 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.
> 
> 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 variable.

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 now.
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 issue
> 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 
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 
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 sure
> 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 variable objects),
> > > the UI is already useless. GDB is not the problem here.
> > 
> > Right, but for us the 1000 varObj are not meant to all be displayed at once
> > but are a caching system.
> 
> I'm still not sure what you mean -- you mean that a variable object is not shown
> in any widget, but only is stored in the cache? What is the key of the cache?

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 same 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:
> > > 
> > > 1. The size of array is too large to keep all varobj always created.
> > 
> > I'm not sure what you mean here.  Before Nick's patch, issuing -var-list-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.
> 
> Well, then, the problem is in *your* code :-) If GDB has no problem creating
> variables objects for all children, but your cache fills up, then you have 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 arrays",
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.
> > 
> > This is probably not a valid use case... although user behavior, even when dumb :-)
> > should not break the frontend.
> 
> Yes, this is my "Oops" use case -- we should create some reasonable number of children
> initially, and incrementally fetch more per user request, thereby giving the user a
> chance to stop :-)

Exactly.

> 
> > But you got me thinking now... Maybe var-create using with an array slice is all we
> > need for dealing with a large array?
> 
> 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; the "slice"
is not increased but instead, a new "slice" is created.

Marc