[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-users] Generated AjcClosure classes
|
Hey,
> Great to hear this. Or not :) because I'm currently writing a paper about these things.
> As a cache key I use a hash of the bytecode of the unaltered class. After I compute the hash, I weave aspects to the class and save the weaved class into the cache.
> On subsequent program executions, I recompute the hash and retrieve the weaved version. When the list of aspects I instrument classes with changes, I invalidate the cache.
> Thus, after changing the list of aspects, on subsequent runs, a new cache is rebuilt.
Ok, let me throw something out there and you can tell me if you have
considered this case, as it seems the big problem :) The hash of
aspects and the class to be woven is not actually sufficient. Suppose
I have this:
aspect X {
before(): execution(* Foo.*(..)) {}
}
class A extends B {
public void m() {}
}
class B { }
class Foo {
public void m() {}
}
on first building/weaving that system, type A will not be woven. You
will cache it according to hash#A and {X}
Suppose I then change B:
class B extends Foo {
}
Now you reload the system. A hasn't changed, neither has X, but A
would now be woven because B changed - so if you use the cached entry,
you will get the wrong result.
I am thinking that hashing of the bytecode for 'A' isn't sufficient
for the key, and perhaps it is more a hash of A 'plus dependencies
that affect decisions made during weaving'. That latter information
is something the weaver can know, and if included in the cachekey in
some way, we can know that a change to B also means the cache value
for A is out of date. Do you have another solution to this problem?
This is why I was thinking about AspectJ doing its own caching,
because it can know all these things.
> One thing I'm considering is having caches for each sequence of applied aspects so as to not start from scratch if there is a common sub sequence between what I already cached and the new list of aspects.
Yes, that is common with a profiling aspect where it is off, then you
turn it on, then you turn it off again.
>> There currently isn't a way for you to get at them I don't think - but
>> there have been other requests to access them, or at least be made
>> aware of them. This wasn't for a caching purpose but merely to avoid
>> clashes in the case where an attempt is made to define the same class
>> twice (https://bugs.eclipse.org/bugs/show_bug.cgi?id=287426).
> So what happens with the $AjcClosure classes? Isn't there a way I can get their bytecode? WeavingAdaptor has a method called "accept" that sounds to do just that. Also, the WeavingAdaptor constructor takes in a "GeneratedClassHandler". Is there a way I can get a hold of that handler from within "Aj"?
If you override functionality at a lower level, yes you can be plugged
into the process (GeneratedClassHandler), but I thought you were
running ltw as a standalone agent and then plugging your agent in
separately - are you not doing that? Are you having your agent work
with the LTW agent?
As I say, raise an enhancement request to discuss this.
Andy