Stephane,

You query just happened to coincide with one of my occasional perusals of 
this list so I thought I'd chime in...

I can't speak about the current state of VW but the virtual machine 
implementations I was involved with certainly only reified the stack when 
forced to via thisConext.  I believe that this approach was shared by most 
other high performance VMs of that generation and that it was generally 
considered to be essential to achieving good performance.  I touched upon 
this technique a bit in my OOPSLA 86 paper "A Third Generation Smalltalk-80 
Implementation".  My recollection is that Elliot Miranda talked about this 
more extensively in his OOPSLA 87 paper on BrouHaHa and that it probably was 
discussed in the original Deutsch&Shiffman POPL(??) paper on PS.

Much of the complexity of this approach revolves around transitioning 
execution between already reified contexts and the unrefied stack. 
Simplifying (and minimizing) such transitions was one of the motivations in 
my implementations for changing from the original blue book BlockContext 
design to a more proper closure design where the block closure object is 
distinct of the activation records that are needed when the block is 
evaluated.

What I always consider a key optimization was finding a scheme that avoided 
the need to reify the stack every time a block closure is created. I 
described an approach for doing this  a number of years ago on this list. 
See 
http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-April/008237.html

BTW, its interesting that Digitalk's VMs did not have an explicit 
thisContext operation and never bothered to have explicit context objects. 
When necessary, the execution stack was reified into unstructured array 
objects.  If Smalltalk code needed to analyze these reified stacks they had 
to do all the work to parse them into distinct activation records. Of 
course, using some context-like facade objects was a big help to such stack 
processing.  In hindsight, the absence of thisContext never seemed to be a 
major impediment for VisualSmalltalk and its absence gave the VM designer a 
bit more flexibility in the design of the actual execution environment.

Hope this helps,
Allen


----- Original Message ----- 
From: "stephane ducasse" <stephane.ducasse at free.fr>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Friday, January 19, 2007 2:25 AM
Subject: Stack reification and JIT interaction question


> Hi
>
> We have a deep discussion on execution stack reification and we want  to 
> know if there is
> a difference between the blue book and VW.
>
> Basically I wrote in a article that in Smalltalk the execution stack  is 
> causally connected and reified on demand.
> - causally connected because if I change the object that represents  the 
> stack the stack changes (as show
> by the example below)
> - reified on demand measn that the stack is not always a first class 
> objects that
> I can access via message sends but only when thisContext is used or 
> exceptions.
>
> Lukas told me that in Squeak this is always an object and that the  blue 
> book shows that too.
>
> So I wanted to know in VisualWorks in presence of a JIT if this is  the 
> case.
> My question basically is when a method is executed in the assembly,  is it 
> a smalltalk object,
> can we send it messages (I thought not).
> Is the stack reified only when using thisContext?
>
> Is this correct?
>
> Stef
>
>
>
> test 1
> self test2.
> Transcript show: 'Called test2'; cr
>
> test2
> self test3
> Transcript show: 'Called test3' ;cr
>
> test3
> thisContext sender: thisContext sender sender
>
>