modification of ContextPart?
Klaus D. Witzel
klaus.witzel at cobss.com
Sat Nov 12 19:02:33 UTC 2005
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
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
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
We hope you will tell us when and how you eventually achieved your goal ;)
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.
More information about the Squeak-dev