Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Generated AjcClosure classes

Hello,
On Dec 2, 2009, at 7:10 PM, Andy Clement wrote:

> 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.
Thanks for pointing this out. That is a problem. Currently, I was not thinking of systems that can change their code. Having this mentioned, I believe there is a non-aspect, albeit more inefficient way: when a class is loaded, Java will also load its superclass, interfaces, etc. Now, if those changed, I think it's safe to invalidate the current class as well and have it (re)weaved. Even if these super classes are already loaded, my analysis looks at all the classes the current class interacts with and I can manage to find that they changed as well. However, this solution incurs the overhead of reweaving classes that do not have to be modified.
> 
>> 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?
I have an agent in which I use Aj as a secondary agent. This architecture gives the option of easily implementing the cache verification without having to modify Aj.
> 
> As I say, raise an enhancement request to discuss this.
How do I do that?

Cheers,
	Silviu
> 
> Andy
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users



Back to the top