Michael,

I just read your paper "Virtual Machine Support for Aspects with Advice  
Instance Tables" - was not aware that you're hacking Jikes and the like ;)

You can always add a new temp (max temps is 64...) to any existing method  
by modifying MethodNode>>generate: (nTemps: + 1) and recompiling,  
regardless of what the method declares and without modifying the source  
method. Then access the new temp (which from here on is only known to you  
:) by
  ctx tempAt: ctx method numTemps put: anAdviceInstance

This is compatible in case of saving/loading images and does not need a  
change to the VM and achieves the smallest possible runtime performance  
penalty :)

And if I understood your first message correctly, you want that  
BlockContext has its advice instance propagated from its creating  
MethodContext (and so on). If so: happily the temps of BlockContext are  
maintained in their respective "home" MethodContext (have a look at the  
implementors of #tempAt:) so, nothing else is needed.

Of course some testing is necessary before the above can be taken as  
granted...

We hope you will tell us when and how you eventually achieved your goal ;)

/Klaus

On Sat, 12 Nov 2005 19:09:37 +0100, Michael Haupt <mhaupt at gmail.com> wrote:

> Hi Klaus, Bryce,
>
> thank you for your comments!
>
> Klaus, I'm afraid I don't have the amount of control over the methods
> that would be needed to make them declare a new local variable. Since
> the idea of AOP is, to a certain extent, to impose aspectual behaviour
> on functionality that is not necessarily aware of such extensions,
> preparing methods for it would break the programming model.
> Nevertheless, thanks for the solution.
>
> Bryce, you're right; a modified VM of course means that the images
> can't run on other VMs. That's "ok" from my perspective. The
> Interpreter>>activateNewMethod method is a good hint, thanks! I'll see
> if I can find another solution that doesn't imply changes to the VM.
>
> Best,
>
> Michael
>
>