Stack reification and JIT interaction question
Allen Wirfs-Brock
allen at wirfs-brock.com
Sun Jan 21 22:30:38 UTC 2007
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" <stephane.ducasse at free.fr>
To: "Allen Wirfs-Brock" <allen at wirfs-brock.com>
Cc: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, January 21, 2007 1:03 PM
Subject: Re: Stack reification and JIT interaction question
> Thanks Allen
>
>> 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.
>
> 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
More information about the Squeak-dev
mailing list
|