On 10/26/2010 01:24 PM, John Cortell wrote:
<snip> 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.
<snip>
I don't think that's the case for the Transaction as implemented in bug
31345. That's because the request monitor which is passed to a cache
in ICache.update() ends up holding the strong reference to that cache.
However, this reference is for a cancel listener and could change with
future changes to RequestMonitor. It would be better to add the strong
reference to the cache in Transaction itself.
There's another problem to keep in mind. Unless the cache objects
themselves are listeners to events, it's important to hold the cache
objects in the cache as long as there are strong references to it.
Otherwise a client holding a cache object may be reading stale data
which should have been invalidated through the cache manager. I guess
this is another way to look at the 2.b.i statement, where leaf nodes
should be collected before parents.
Also, using weak references could leave the cache being purged too
aggressively. A combination of soft references and weak references
would solve the problem.
.... I'm looking forward to see what you come up with :-)
Cheers,
Pawel
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|