[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] One target for intertype declarations
|
David and Eric,
>aspect myAspect {
> private interface State {};
> declare parents: * && !java.lang.Object implements State;
> MyState State.ref = null; // will point to my associated state
>
> ...
>}
This is pretty much the way that per-object aspects are implemented (this
is turning into an aspectj-dev rather than aspectj-users discussion).
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
df
>>> Is 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
