[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] MI varobj cache
|
On 09/23/2014 05:41 PM, Marc Khouzam wrote:
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Vladimir Prus [vladimir@xxxxxxxxxxxxxxxx]
Sent: September 23, 2014 3:08 AM
To: CDT General developers list.
Subject: [cdt-dev] MI varobj cache
Hi,
current DSF-GDB has a cache for MI variable objects, MIVariableManager.LRUVariableCache. I see its size is 1000,
and it counts not just root variable objects, but also children. That leads to couple of problems:
- There are more registers than that on my target, and they all can reasonably change between two stops, so
it will thrash this cache
Variable Objects are only added to the cache when actually displayed in the view. That means that unless you expect
the user to scroll through all registers at every stop, the cache should still remain relatively stable. So I agree that
the situation is not ideal, but it is also not as bad as it sounds.
Depends on what you mean by "the view". In my case it's a custom graph view, so it can show quite a lot of values,
and it's not easy to determine what values will be visible, so it's easier to just fetch everything.
- The varobjs will be likely created in a special way, so if the cache decides to delete a varobj,
there won't be a way to recreate it (unless I modify GDB even more).
I don't understand this. MIVariableManager uses MI commands to create the variable objects.
Why would it be able to create them properly once and not more than once?
Because -var-registers creates varobjs for all registers, and there's no interface to create varobj for Nth
register specifically. Maybe I shall add this, though removing individual child varobjs and then creating
it again won't be highly efficient approach.
I can't quite change cache size, since it's private static field in a private class. Should it be more
customizable?
Sure, if that helps. Although I wonder about caching so many elements...
It should not have much of impact on CDT side. Now, GDB uses a hash table with 227 buckets for store
varobjs (yay hardcoded limits), so we'll quickly run into problems there, but then GDB will hopefully
be C++ soon, with proper data structures.
I can't mark a varobj as precious, so as to prevent any garbage collection. Would that be good idea?
That is interesting, if you can write a data struct that does that relatively simply.
Let's make sure the requirement is really valid before increasing the complexity though.
Yeah, I'm playing with totally new view and DSF service right now - but not reusing anything of MIVariableManager
is also bad.
Why do we actually need this cache in the first place?
We need to remember which variable objects are created in GDB so that we can use -var-update on them. Without
that knowledge, we'd have to re-create the varObject every time, which defeats the purpose of variable objects altogether,
and we'd be better off just doing a -data-evaluate-expression every time (not to mention all the features of varObjects we'd
loose like knowing if the object is writeable).
That sounds like an argument for having the cache size as big as practically possible ;-) Why not make it infinite?
It would be a bit concerning that we can potentially keep a lot of varobjs we'll never need, but then we can expire it
based on the number of stop events that passed since last use - if we stopped in function foo and asked for 'i' once,
then it would be nice to reuse varobj if we ever stop in 'foo' in future, but that's less important that keeping
varobjs around while we're stepping inside the function. That would prevent cache from infinite growth, but would
make sure that registers/variables/varobjs that are consistently live don't cause any trashing, since such trashing
is strictly worse that just creating varobjs for everything that views request on each stop.
- Volodya
--
Vladimir Prus
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/
