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

Stef,

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

This paper has details about the VisualWorks implementation:

> http://wiki.cs.uiuc.edu/VisualWorks/DOWNLOAD/papers/oopsla99-contexts.pdf

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

Well, any method with machine language code has an associated bytecode
version which *is* an object. You can send messages to that, at least.

> Is the stack reified only when using thisContext?

The stack is a list of Array objects, but the linked list of Context
objects is reified on demand as you said. This is mostly the blue book
design turned inside out: instead of a list of Contexts each with its
own Array and stack pointer you have an Array divided into stack frames,
some of which are associated with Context objects. This explanation is
too confusing - see the paper.

-- Jecel

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" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, January 19, 2007 2:25 AM
Subject: Stack reification and JIT interaction question

Thanks Allen

do you think that seaside could have been built on top Digitalk?
I have the impression that it would have been more difficult. Do I  
interpret correctly that in Digitalk you could not
change the stack from within Smalltalk?

Stef

I'm not sure what the value of a context cache is for a modern
designed high performance VM. Any VM that does dynamic inlining
like Self may be able to reduce the number of method calls to the
point were a context cache isn't worthwhile. After all all common
calls should be inlined.

However if you could inline the contexts as they were faulted into the
context cache then build uninlined contexts as they are faulted out it
may be possible to have very cheap de-optimization. If inlined
contexts are full objects then to remove the compiled code requires
allInstances which does a full memory scan.

Bryce

I'm not really all that up to speed on seaside but my understanding is that
it is based upon continuations so I'll interpret the question as whether or
not it would be possible to implement continuations on top of the Digitalk
VMs.  Without researching the details further I'm not completely sure but I
believe that the answer would be yes.  Once the stack had been reified as a
stack object it was fully mutable from Smalltalk code.  This capability was
certainly used by the debugger and by other subsystems. However, Digitalk
never documented the reified stack format and I believe that the format
actually varied between various Digitalk VMs so code that manipulated it was
dependent upon the underlying VM.

I think what we are really talking about is alternatives for laying the
design of a Smalltalk implementation and at which layer (and using which
implementation technology) various abstractions are implemented. A three
layered execution context implementation  seems quite plausible:
    layer 0:  "native" stack used for interpretation or direct execution of
JITed bytecode
    layer 1:  native stack reified as a stack object
    layer 2: discrete context objects implemented as a facade over the stack
object

Translation between layers 0&1 would probably be implemented using highly
optimized code that was part of the VM.  Translation between layers 1&2
would be done (probably lazily) by Smalltalk code.  Digitalk neglected to
formally provide layer 2...

(I quoted "native" stack above because this might or might nor directly
correspond to processor stack. In some of our implementations we used two
parallel stacks for execution.  One that we called the "control stack"
corresponded to the processor stack and contained return addresses and other
control information including pointers into the second stack.  The second
stack was the "object stack" and only contained OOPS.  All arguments and
method/block temps were stored on the object stack. This greatly simplified
scanning the stack roots by the GC and made if very easy to reify it as an
array object. )

Allen


----- Original Message -----
From: "stephane ducasse" <[hidden email]>
To: "Allen Wirfs-Brock" <[hidden email]>
Cc: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Sunday, January 21, 2007 1:03 PM
Subject: Re: Stack reification and JIT interaction question