I will let marcus comment on this one.
It seemed to me that with byteSurgeon we could add a new temp  
transparently and assign a value to it.
and without "recompiling".
This is the goal of byteSurgeon "letting us tweak the bytes".


> Hi Stef,
>
> after increasing nTemps of a CompiledMethod by 1, you wouldn't be  
> able to see that you have already done so (in case you change+run 
> +change+run incrementally, I mean) and soon run out of temp space :(
>
> I think one must recompile for to be sure and, that there is most  
> likely no other approach for safely increasing nTemps by one more  
> than a source method declares ;)
>
> /Klaus
>
> On Sat, 12 Nov 2005 20:35:45 +0100, stéphane ducasse  
> <ducasse at iam.unibe.ch> wrote:
>
>
>> you could also use bytesurgeon for doing that. :)
>>
>> Stef
>>
>> On 12 nov. 05, at 20:02, Klaus D. Witzel wrote:
>>
>>
>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>