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