| Re: [aspectj-users] One target for intertype declarations |
Hi Matthew,Thanks for this reply - it's answered my question and things are pretty much as I expected. One thing, though, is that I don't see how only one field could be added per object to implement pertarget.
In fact, I decompiled an example and as far as I can tell there is one field introduced per class, meaning that classes composed using inheritance contain multiple instances of the field. I've attached a test case. Is this right?
Cheers, Dave
However I think there is a subtle difference between Eric's bug and David's question. The bug concerns the introduction of the object-aspect association into classes that can _never_ be associated with an aspect i.e. the per-clause pointcut will never match. David's question relates to the overhead for classes that _could_ match but don't in a particular run-time scenario. Unfortunately you cannot add fields (unless you use hot code replace which brings it's own baggage to the party) _after_ a class has been defined and objects instantiated so any object that _could_ be associated with an aspect will carry the overhead. Alternative association mechanisms (Hashtables etc) have there own problems like pathlength, synchronization and garbage collection. Sampling instrumentation is a special use-case for AOP/AspectJ so it is quite likely you will have to roll-your-own implementation for efficiency as general purpose mechanisms won't do exactly what you want. Matthew Webster AOSD Project Java Technology Centre, MP146 IBM Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196 2816139 (external) 246139 (internal) Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx http://w3.hursley.ibm.com/~websterm/ Eric Bodden <eric@xxxxxxxxx>@eclipse.org on 19/11/2004 07:29:19 Please respond to aspectj-users@xxxxxxxxxxx Sent by: aspectj-users-admin@xxxxxxxxxxx To: aspectj-users@xxxxxxxxxxx cc: Subject: RE: [aspectj-users] One target for intertype declarations -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Pearce wrote:Hi Eric,ITDs cannot hold aspect instances since normally such instances cannot be created by hand. Google for "association aspects" for a different approach.Ok, but that's a minor difference since all I want is to associate state with an object. So, it doesn't have to be an aspect instance --- a simple data structure holding my state will suffice.Ok idf you really want to associate aspects with objects then you should definietely read http://www.komiya.ise.shibaura-it.ac.jp/~sakurai/aa/aosd2004aa_slide.p dfIs the reference put into all objects matching the pertarget pointcut, or just into objects for which an aspect is created?Isn't that the same? One aspect instance is created for any object matching the pertarget pointcut.Well, I was thinking of something along the following lines: aspect myAspect pertarget(initialization(*.new()) { static int counter = 0; before() : initialization(*.new(..)) && !within(myAspect) && if(++counter > 100) { ... counter = 0; } } The point about this is that the advice is only entered every 100th time. Meaning that an aspect is only created every 100th time. So, the question is, is there an empty (aspect) reference field for objects which match the pertarget specifier, but never make it into the advice?At the moment, I can say *yes*. However, I actually reported that as a bug, because this is not what one wants. It just leads to unnecessarly codebloat since you would not be able to directly *access* that field anyway. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=78383 for details.The reason I want to do this is simply to associate state with "some" objects, rather than all (i.e. Sampling). Furthermore, i would rather not have any memory overhead associated with those which have no state associated with them.Again, read the above paper.One a slightly different note, one thing does occur to me in the pertarget versus ITD discussion. Consider the following alternative: aspect myAspect { private interface State {}; declare parents: * && !java.lang.Object implements State;Off-topic: Is that valid syntax not? I thought I had read that ClassSignatures would not allow boolean combinations yet...MyState State.ref = null; // will point to my associated state ... } I think that State.ref will be introduced into every class, meaning objects composed using inheritance will have multiple copies of it? In this case, there is a difference from pertarget, where I presume there can only ever be one reference per object. Comments?No, as I understood, for declare parents, such fields are only generated once for an object and all its supertypes that might be matched the same ITD. At least, that's the only sensible implementation IMHO. And again: You usually cannot access that field anyway! Hope, that helps, Eric - -- Eric Bodden Chair I2 for Programming Languages and Program Analysis RWTH Aachen University -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQZ2gzswiFCm7RlWCEQJAFQCghHpMXOMfYd1jWuxZl1uCE/b10E0An0Sg fcFckTYi9WfEz8gM7zPKybx2 =5Ve5 -----END PGP SIGNATURE----- _______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/aspectj-users
Attachment:
pertargetTest.tgz
Description: Binary data