RE: [aspectj-users] Custom JoinPoints

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

Wes,

>But the VM can treat any unreachable
reference as eligible for GC.  Something can
>be on the stack passed as a parameter
but unreachable to executing code.  And as I
>pointed out, the programmer need not
set it to null for the VM to conclude it won't be 
>used again, but it can help.
GC will _never_ collect an object referenced
from the stack. GC does not look through your code to see if you might
use it again. Therefore all object references passed as method arguments
are live for the duration of that method.

>I wouldn't support one or many custom
join point factories if it 
>involved breaking the AspectJ programmer's
model, which I believe
>includes sharing both state and changes
to that state.  So the multiple
>join-point instances should look like
one instance: same hashcode
>for advice on the same join point (arguable),
and context changes 
>are visible to less-precedent code (required).
 So the fact that 
>at the start of the join point the different
join point instances
>refer to the same context variable doesn't
help when a client
>of one of the join point instances replaces
a reference in a 
>proceed(..) statement.  Less-precedent
advice of all aspects should
>see that different reference.
A model that required all custom join
point instances that represent the same join point to be equal is unworkable.
I think the contents of thisJoinPoint are considered read-only transient
meta-data. My investigation shows that in order to change method argument
values with around() advice you need to use args().

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/

"Wes" <wes@xxxxxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx

20/10/2006 06:00

Please respond to
wes@xxxxxxxxxxxxxx; Please respond to
aspectj-users@xxxxxxxxxxx

To	aspectj-users@xxxxxxxxxxx
cc
Subject	RE: [aspectj-users] Custom JoinPoints

Matthew Webster wrote:
 
In your example below the two invocations
of go() are separate join points 
 
doh, obviously.
 
>  the JoinPoint instance is passed
as a argument to the advice method 
> so is on the stack and so cannot be
collected. 
 
But the VM can treat any unreachable reference
as eligible for GC.  Something can
be on the stack passed as a parameter but
unreachable to executing code.  And as I
pointed out, the programmer need not set
it to null for the VM to conclude it won't be 
used again, but it can help.
 
>>Currently the same join point instance
is shared by multiple advice
>>in different aspects. 
> Correct, but this would have to change and any aspect associated with
a custom 
> JoinPoint factory would get its
own custom instances. How else would you support 
> multiple custom factories?

 
I wouldn't support one or many custom join
point factories if it 
involved breaking the AspectJ programmer's
model, which I believe
includes sharing both state and changes to
that state.  So the multiple
join-point instances should look like one
instance: same hashcode
for advice on the same join point (arguable),
and context changes 
are visible to less-precedent code (required).
 So the fact that 
at the start of the join point the different
join point instances
refer to the same context variable doesn't
help when a client
of one of the join point instances replaces
a reference in a 
proceed(..) statement.  Less-precedent
advice of all aspects should
see that different reference.
 
Wes
 _______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users