[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Multicore Visualizer on 576 cores
|
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Xavier Raynaud
> Sent: Friday, June 27, 2014 4:08 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Multicore Visualizer on 576 cores
>
> Hi Marc,
>
> [...]
> >> (2) When visualizer connects, he does the same things: so we have to
> >> wait twice longer.
>
> > If the visualizer uses the DSF services, the caching mechanism should
> > kick in and there should be no need to go back to GDB for the
> > information that was already fetched.
>
> I've seen that. I started to use the caching mechanism, and I gain a few time.
> Note: I didn't found any documentation about DSF caching mechanism. Is it
> documented somewhere ?
Not that I know of. Normally we use the class CommandCache.java to cache
GDB commands and answers, to avoid having to send them again. That
cache has traces you can enable under o.e.cdt.dsf/debugCache to see
when the cache is hit.
The idea is that when you send a GDB command through the cache
and that command was sent before, the cache will immediately answer
with the recorded result; if the command is not in the cache, it will
send it to the commandControl service to send to GDB.
That cache must also be cleared and appropriate events, depending
on the situation.
You can look at how it is used in our different existing services.
In some cases, you may choose to implement your own caching
structure if the CommandCache does not suit your needs.
I hope this helps.
Marc
