VM & Runtime stack

> Hi!
>
> In Squeak, the stack is reified upon the execution of the  
> thisContext bytecode. Else, the stack is not reified. So comes my  
> question: Where is the stack stored ? Is there a dedicated part of  
> the memory ?
>
> Cheers,
> Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>

> Hi Alex,
>
> No, there is no real reification (depending on the definition of  
> course). The contexts used by the VM are the very same objects you  
> get at the image level. Plain old Smalltalk objects...
>
> The only special thing about contexts is that they are recycled, if  
> possible. The VM holds a list of contexts that can be reused. If  
> you access thisContext (through the special bytecode), this context  
> and any other context not returned from (i.e., still on the stack  
> of the active process) cannot be recycled anymore. As far as I  
> remember, also when switching process or when doing a GC, the cache  
> is flushed. (I once did a statistic about how many contexts are  
> actually recycled compared to being newly instantiated, and only  
> got around 6-10%, which is much less than what I expected.)
>
> Cheers,
> Adrian
>
> ___________________
> Adrian Lienhard
> www.adrian-lienhard.ch
>
> On Jul 16, 2007, at 12:47 , Bergel, Alexandre wrote:
>
>> Hi!
>>
>> In Squeak, the stack is reified upon the execution of the  
>> thisContext bytecode. Else, the stack is not reified. So comes my  
>> question: Where is the stack stored ? Is there a dedicated part of  
>> the memory ?
>>
>> Cheers,
>> Alexandre
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>
>
>
>

> Hi Alex,
>
> No, there is no real reification (depending on the definition of  
> course). The contexts used by the VM are the very same objects you get  
> at the image level. Plain old Smalltalk objects...
>
> The only special thing about contexts is that they are recycled, if  
> possible. The VM holds a list of contexts that can be reused. If you  
> access thisContext (through the special bytecode), this context and any  
> other context not returned from (i.e., still on the stack of the active  
> process) cannot be recycled anymore. As far as I remember, also when  
> switching process or when doing a GC, the cache is flushed. (I once did  
> a statistic about how many contexts are actually recycled compared to  
> being newly instantiated, and only got around 6-10%, which is much less  
> than what I expected.)

> Cheers,
> Adrian
>
> ___________________
> Adrian Lienhard
> www.adrian-lienhard.ch
>
> On Jul 16, 2007, at 12:47 , Bergel, Alexandre wrote:
>
>> Hi!
>>
>> In Squeak, the stack is reified upon the execution of the thisContext  
>> bytecode. Else, the stack is not reified. So comes my question: Where  
>> is the stack stored ? Is there a dedicated part of the memory ?
>>
>> Cheers,
>> Alexandre
>>
>> --_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>
>
>
>
>

> Where, how did you get/make those benchmark?
>
>         Mth
>
>
>
> On Jul 16, 2007, at 11:02 PM, <[hidden email]>
> <[hidden email]> wrote:
>
> > I just benchmarked with and without context recycling
> > using tiny benchmarks:
>
>
>

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

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

> 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 17/07/07, Mathieu Suen <[hidden email]> 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].
>>
>>
>>
>
>

> On Tue, 17 Jul 2007 04:16:28 +0200, sig wrote:
>
> > On 17/07/07, Mathieu Suen <[hidden email]> 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.
>