Re: [aspectj-users] AspectJ and memory management

[Adrian Colyer <adrian_colyer@xxxxxxxxxx>]

> Invocations of Y on A instances should be delegated to a memory-managed 
> Z instance. Z should preferably be a straight implementation of Y, i.e. 
> an ordinary JavaBean/POJO.
> 
> There are two issues, framework-wise, that has to be done: 1) add the Y 
> interface to A 2) delegate Y invocations on A to an instance of Z, where 

> the Z instance can be managed by factory/cache somehow. As far as I can 
> tell, after discussing it with Wes off-list, is that 2) is not possible.

Got it :)

1) is easy, as shown in the previous example

aspect X {
  declare parents : A implements Y;
  ...
}


2) is more complex.

You'd like to write this:

  pointcut invocationOfYonA(Y y) : execution(* Y.*(..)) && target(y) && 
target(A);

  Object around(Y y) : invocationOfYonA(y) {
      // ask the framework for the real dispatch target, which should
      // create one if necessary...
        Y dispatchTarget = framework.getDispatchTargetFor(y);
      return proceed(dispatchTarget);
  }

but as I'm sure Wes pointed out, this only works when 'dispatchTarget' is 
an instance of the same concrete class as 'y' (in this case, an instance 
of A, which is not what you want). 

You can however write this:

  pointcut invocationOfYonA(Y y) : execution(* Y.*(..)) && target(y) && 
target(A);

  Object around(Y y) : invocationOfYonA(y) {
      // ask the framework for the real dispatch target, which should
      // create one if necessary...
        Y dispatchTarget = framework.getDispatchTargetFor(y);
      Object ret = dispatch(dispatchTarget,thisJoinPoint);
      return ret;
      // note the absence of a call to proceed in this advice body, which 
prevents the
      // original method on A from executing
  }

  // needs suitable exception handling...
  private Object dispatch(Object target, JoinPoint jp) {
    CodeSignature sig = (CodeSignature) jp.getSignature(); // assumes only 
called from above
    Method m = 
target.getClass().getMethod(sig.getName(),sig.getParameterTypes());
    return m.invoke(target,jp.getArgs());
  }
 

which is not as pretty, but if its part of your framework code it could be 
optimised etc....

-- Adrian
Adrian_Colyer@xxxxxxxxxx



Rickard Öberg <rickard@xxxxxxxxxxxxx> 
Sent by: aspectj-users-admin@xxxxxxxxxxx
11/08/2004 12:51
Please respond to
aspectj-users


To
aspectj-users@xxxxxxxxxxx
cc

Subject
Re: [aspectj-users] AspectJ and memory management






Adrian Colyer wrote:
> I think we're all grappling to really understand your question. As Wes
> alluded to, the terminology you use is quite confusing. 

Yeah, I've realized now that I used the "perthis" word inappropriately.

> Let me try and
> clarify what you are asking, and then once that is established we can 
let
> you know the answer!
> 
> 
>>if a class A....
> 
> 
> class A {
>   void aardvark() {}
> }
> 
> 
>>has a stateful "perthis" introduction X
> 
> 
> this bit is very confusing....

Yes, ignore the "perthis" part...

>>which adds an implementation of the interface Y to A
> 
> 
> but here we can attempt error recovery.....
> 
> do you mean:
> 
> interface Y {
>    void whyOhWhy();
> }
> 
> aspect X {
>   declare parents : A implements Y;
>   private String A.reason = "Ours is not to reason why"; // just to give 
us
> some state
>   public void A.whyOhWhy() { System.out.println(reason); }
> }
> 
> ?

That's basically it, except the implementation should not know about 
where it is applied (the declare part), and I need to do memory 
management of the whole X instance using lazy-loading.

>>then I want to control how instances of X are managed
> 
> in the example above, each instance of A will have its own reason field.
> There will only be one instance of X.
> 
>>an invocation of Y on A must enable X to be instantiated...
> 
> this doesn't make sense to me yet (certainly not in the context of the
> example above). If I change things slightly.....
>   "an invocation of Y on A must enable Z to be instantiated..."
> 
> aspect Z percflow(invocationOfYOnA()) {
> 
>  pointcut invocationOfYOnA() : execution(* Y.*(..)) && target(A);
> 
>   public Z() {
>     // load persistent state etc....
>   }
> }
> 
> you have a model where each invocation of a method on Y creates a new
> instance of Z which can be GC'd after returning from the execution of 
Y's
> method.

Right, except it's more like "..may create a new instance..". If one is 
already created it should be reused. And it must be GC'able any time it 
is not being used for an invocation.

> I guess you could actually collapse X and Z into one aspect if that is 
what
> you are asking:
> 
> aspect X percflow(invocationOfYOnA()) {
>   declare parents : A implements Y;
>   private String A.reason = "Ours is not to reason why"; // just to give 
us
> some state
>   public void A.whyOhWhy() { System.out.println(reason); }
> 
>  pointcut invocationOfYOnA() : execution(* Y.*(..)) && target(A);
> 
>   public X() {
>     // load persistent state etc....
>   }
> 
> }
> 
> If Z can be independent it doesn't need to be an aspect.... you could
> write:
> 
> aspect X  {
>   declare parents : A implements Y;
>   private String A.reason = "Ours is not to reason why"; // just to give 
us
> some state
>   public void A.whyOhWhy() { System.out.println(reason); }
> 
>  pointcut invocationOfYOnA() : execution(* Y.*(..)) && target(A);
> 
>  before() : invocationOfYOnA() {
>    Z z = new Z();  // do whatever z does
>    // presumably give someone a reference to z otherwise it will go out 
of
> scope immediately
>    // can manage lifecycle of z as you wish
>  }
> 
> }
> 
> Are any of these getting close to the question you are asking?

Invocations of Y on A instances should be delegated to a memory-managed 
Z instance. Z should preferably be a straight implementation of Y, i.e. 
an ordinary JavaBean/POJO.

There are two issues, framework-wise, that has to be done: 1) add the Y 
interface to A 2) delegate Y invocations on A to an instance of Z, where 
the Z instance can be managed by factory/cache somehow. As far as I can 
tell, after discussing it with Wes off-list, is that 2) is not possible.

Sorry for the confusing examples/terminology!

/Rickard

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users