VM & Runtime stack

Klaus D. Witzel klaus.witzel at cobss.com
Tue Jul 17 08:10:24 UTC 2007


On Tue, 17 Jul 2007 04:16:28 +0200, sig wrote:

> On 17/07/07, Mathieu Suen <mathk.sue at gmail.com> wrote:
>> Actualy not when a precess switch occure or not when thisContext is
>> used.
>> But is true that the from now the block need to push the context and
>> this bytecode flush the context cache.
>> This is not a good things since the context may not be used inside
>> the block.
>> The only case when the context shouldn't be recycle is when the block
>> is pass as a return value or assign to an inst var,class var,  global
>> var....
>>
>> This because:
>>   MethodContext goes to the cache when the VM return from the method.
>> The BlockContext have a reference to the MethodContext
>>
>> But there is some block where the context aren't push on the stack.
>> Actually is for special send that are inlined (#to:do:,
>> #ifTrue:ifFalse: #caseOf: and so on) so block aren't created.
>>
>>         Mth
>>
> Compiler, in most cases, can figure out if block requires MethodContext  
> or not.

Perhaps you mean BlockContext.

> I don't know much about Squeak compiler, but inspecting Dolphin
> bytecode shows that they having set of flags to indicate if block uses
> MethodContext, self e.t.c..
> For instance, block like: [ literal message ] , [ SomeClass message ]
> ] , which don't use any method's temps/args/self/returns
> can be executed from anywhere returning same result, thus they can be
> prepared for execution differently to avoid unneeded checks/flushes
> e.t.c.
>
>>
>> On Jul 16, 2007, at 4:04 PM, Klaus D. Witzel wrote:
>>
>> > FWIW, over in the newcompiler list we recently discussed various
>> > implementation details, from the new compiler down to the VM level,
>> > of full BlockClosures. It turned out that as soon as BlockClosures
>> > receive full (performant) support from the VM then breaking the
>> > recycleable context rule no longer occurs and recycling can happen
>> > 100%[tm].
>>
>>
>>
>
>





More information about the Squeak-dev mailing list