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
|