Re: [aspectj-users] AspectJ and memory management

[Adrian Colyer <adrian_colyer@xxxxxxxxxx>]

I think we're all grappling to really understand your question. As Wes
alluded to, the terminology you use is quite confusing. 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....

> 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); }
}

?

> 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.

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?

-- Adrian.
adrian_colyer@xxxxxxxxxx





10 August 2004 18:48
To: aspectj-users@xxxxxxxxxxx
cc:
From: Rickard Öberg <rickard@xxxxxxxxxxxxx>
Subject: Re: [aspectj-users] AspectJ and memory management



Noone knows anything about this, or is it really impossible to do?

Is noone using AspectJ with enormous object graphs? If yes, then how do
you handle it?

Rickard Öberg wrote:
> Hi!
>
> I am investigating how it would be possible to implement memory
> management techniques for introductions in AspectJ.
>
> Basically, if a class A has a stateful "perthis" introduction X, which
> adds an implementation of the interface Y to A, then I want to control
> how instances of X are managed. Specifically, an instantiation of A
> should not cause an instantiation of X. An invocation of Y on A must
> enable X to be instantiated and loaded with persistent state, and after
> the invocation it must be possible to GC X (compare this with, for
> example, JDO and EJB EntityBeans). This allows for the construction of a
> scalable domain model using introductions.
>
> I've looked around in the documentation but can't find much info on how
> introductions are managed, in this sense. Is what I'm after possible to
> do in AspectJ?
>
> If yes, then how? If no, then why not?

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