Re: [cdt-dev] EDC and asynchronous operations

[John Cortell <rat042@xxxxxxxxxxxxx>]

I'm not concerned with the bloat caused by the data maintained by the
cache objects. In the absence of an efficient source-driven invalidation
policy, a cache object can always resort to invalidating itself at the
receipt of any source event. For debugger operations, much of the
caching that's useful happens while the target is stopped, and the
debugger engages in a burst of data gathering activity. When the target
resumes, though, all bets are off for most of the data a debugger would
have cached. Thus, I don't foresee a ton of data being left in the ACPM
cache objects over time.

However, the lifetime of the cache objects themselves is my concern. I
believe you speak to this in 2.b. Even though an invalidated cache object
is lightweight, we need to ensure the collection of these items doesn't
grow uncontrollably throughout the lifetime of a debug session. Java weak
references are generally helpful  for cache implementations, but
indeed their use in this case needs caution. With no outstanding strong
references to a cache object between transaction re-attempts, a GC run
could end up purging a cache object that is involved in the transaction.
That will require an additional attempt to complete the transaction. And
if GC-ing cleans up that or another cache object also used in the
transaction, the subsequent attempt may be thwarted yet again. And of
course, this could go on perpetually. One way around that is to mark
cache objects that have been involved in a failed transaction (due to an
invalidated cache) and prevent their cleanup. When the transaction
eventually completes successfully, the protection can be removed. That's
a measure I've implemented in my cache manager.

John


At 02:02 PM 10/26/2010, Burton, Felix wrote:

Content-Class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01CB7540.662D4528"

Hi John,
 
I agree, this is an important part of ACPM or any caching for that matter. There are different aspects to this:
1.       Keeping the cache consistent
a.       For the most part TCF services define events that control the consistency of the cache.  A client needs to act on these events to get proper results.
b.      There are services, e.g. Processes service, which do not have events.  In those cases the client needs to have a invalidation strategy, e.g. based on a timer, when the queue of pending requests empty, or other strategies.
2.       Limiting memory usage in the client
a.       It is not clear to me how important this is since clients only requires data that it is interested in and at least for debugging, the types of data that get has the potential to be very large is memory and that needs to be flushed when the context is suspended.  Of course in the general case, it is needed.
b.      In an environment, like Java, where there is a garbage collector I think it would be ideal if the cache implementation could be designed to allow the GC to collect cache elements when memory becomes low rather than having a separate mechanism that likely will not have a clear understanding of the correct memory pressure and therefore is likely to be too aggressive not aggressive enough. 
                                                               i.      This would probably require the use of weak references in the right places, so for example leaf nodes in the context hierarchy are collected before parents.
 
Thoughts?
Felix
 
From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Tuesday, October 26, 2010 9:30 AM
To: CDT General developers list.; CDT General developerslist.
Subject: Re: [cdt-dev] EDC and asynchronous operations
 
Felix and Eugene,

One thing I'm finding challenging about ACPM is managing the lifetime of cache objects. These things must live beyond the lifetime of the transaction that uses them since otherwise the transaction will perpetually fail. And when the transaction eventually completes successfully, it's beneficial to not discard the cache objects since there might be a transaction around the corner that needs the same data. At the same time, you don't want to keep piling up the cache objects indefinitely, for obvious memory footprint and performance reasons. So, I've been coding up a manager that tries to take these things into consideration. Did you guys have the same challenge with tcf-debug? Just wanted to check that there isn't some simplistic approach that's not becoming obvious to me.

John

At 04:23 PM 10/12/2010, Burton, Felix wrote:

Regarding 1: I don’t understand what you mean.  The following is simplified pseudo code that count number of frame on a stack by following a frame pointer list.
 
Boolean countStackFrames(Context ctx) {
                TCFDataCache<Register> fp = lookupRegisterCI(ctx, REGISTER_FP);
                if (!fp.validate(this)) {
                                fp.wait(this);
                                return false;
                }
                Address addr = fp.getData().valueAsAddress();
                long count = 0;
                while (addr != 0) {
                                TCFDataCache<Memory> mem = lookupMemoryCI(ctx, addr, address_size);
                                if (!mem.validate(this)) {
                                                mem.wait(this);
                                                return false;
                                }
                                addr = mem.getData().valueAsAddress();
                                count++;
                }
                set(null, null, count);
                return true;
}
 
Regarding 2: I agree, we are not proposing that the asynchronous API should expose ACPM objects like cache instances.  Cache instances can be built on top of an asynchronous API to allow client to use ACPM instead of directly using the asynchronous API.  This is reflected on page 1 in the attached slides.  The TCF box on the bottom is exposing asynchronous APIs and on top of that are cache instances that expose ACPM APIs and on top of that is client code, e.g. code that assembles information that goes into a view, another cache instance, or other client.
 
Hope this helps,
Felix
 
From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Tuesday, October 12, 2010 1:41 PM
To: CDT General developers list.; CDT General developerslist.
Subject: Re: [cdt-dev] EDC and asynchronous operations
 
At 02:47 PM 10/12/2010, Burton, Felix wrote:

Felix, everything you wrote makes sense to me. Again, I definitely see the advantages of ACPM for the client of an async API that needs to make many API calls to carry out an operation. My points have been

1. ACPM is suitable only if you know the superset of all the data points your operation will need. There are many situations where this won't be the case.

2. ACPM seems to me a good tool for the client of an asynchronous API. However, It's not clear to me that an asynchronous API should expose ACPM objects, which I think is what Pawel was hinting at.

John

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev