Stack reification and JIT interaction question
Allen Wirfs-Brock
allen at wirfs-brock.com
Sun Jan 21 20:21:39 UTC 2007
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
>
>
More information about the Squeak-dev
mailing list
|