modification of ContextPart?

Klaus D. Witzel klaus.witzel at cobss.com
Sat Nov 12 20:12:50 UTC 2005


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





More information about the Squeak-dev mailing list