[Vm-dev] postponing tempVector creation
nicolas.cellier.aka.nice at gmail.com
Thu Oct 17 13:34:35 UTC 2013
I had exactly same question yesterday coming to my mind, but isn't it yet
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:
>> Recently I realized that the tempVector is always created at the
>> beginning of the method. In the case of:
>> | 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:
>> | 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...
More information about the Vm-dev