Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] MI varobj cache 
> 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.

> - 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?

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

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

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

> 
> Thanks!
> 
> [FWIW, the 'special-way' is some variant of -var-registers, https://www.sourceware.org/ml/gdb-patches/2006-11/msg00403.html]

Can you give a quick description that explains the problem?

> 
> --
> Vladimir Prus
> CodeSourcery / Mentor Graphics
> http://www.mentor.com/embedded-software/

Back to the top