[Vm-dev] postponing tempVector creation

[Nicolas Cellier]

I had exactly same question yesterday coming to my mind, but isn't it yet
like that?


2013/10/17 Igor Stasenko <siguctua at gmail.com>

>
> how about debugger
> and accessing context state?
> it going to be complicated, since at some stages temps not even allocated.
>
>
> On 16 October 2013 14:53, Clément Bera <bera.clement at gmail.com> wrote:
>
>>
>> Hello,
>>
>> Recently I realized that the tempVector is always created at the
>> beginning of the method. In the case of:
>>
>> foo
>>     | temp |
>>     true ifTrue: [ ^ self ].
>>     [ temp := 1 ] value.
>>
>> It means that even if the execution flow goes to the quick return
>> direction, the tempVector is created even if it is not used. I hacked a bit
>> the compiler to lazily create the tempVector when needed (access to temp
>> Vector variable or block closure creation), which means here the tempVector
>> would be created just before the pushClosure bytecode and not at the
>> beginning of the method.
>>
>> I got as result that this specific method was executed 50,000,000 times
>> per second instead of 21,000,000 times per second. Probably because of some
>> useless garbage collection avoided.
>>
>> The problem of this lazy tempVector initialization is that I never know
>> where I am in the control flow graph. This means than in the case:
>>
>> bar
>>     | temp |
>>     false ifTrue: [ temp := 1 ].
>>     [ temp := 2 ].
>>
>> It is hard to detect where to add the extra bytecode for lazy tempVector
>> initialization, because the first time you need it is in a branch, so if
>> you create the tempVector in the branch and the execution flow goes in the
>> other direction then the tempVector will not have been initialized.
>>
>> Has any of you already investigated in this direction ? Does it worth it
>> to implement that ?
>>
>> Thanks for any answers.
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131017/e492803a/attachment.htm