Complexity and starting over on the JVM (ideas)
tim Rowledge
tim at rowledge.org
Sun Feb 10 23:29:59 UTC 2008
On 10-Feb-08, at 2:53 PM, Michael van der Gulik wrote:
>
> But the execution of that block (a BlockContext?) will be added to
> the top of the current execution stack thus preserving the linearity
> of the stack, right?
Nope.
A stack is linear last-in first-out. In C you branch to a subroutine,
a stackframe is built on the stack and you excute code based on that.
When you return from the subroutine all the memory in that stackframe
is known to be free to reuse immediately if wanted by the next
subroutine call.
If you can get a handle to the actual stackframe and pass it to some
other code then you *cannot* reuse that memory until you have some way
of knowing it is no longer needed. So now you have a sandbar in your
stack and a tricky problem to solve. In squeak we do it the simple
minded way and don't have contiguous stack but instead have actual
explicitly allocated objects in the heap. That completely avoids the
problem, at a cost in performance. VW uses a lot of very clever code
to allow the system to live with a linearised machine compatible stack
and yet present a 'proper' object to the programmer. It works, it's
fast, but the complexity is at times bewildering.
I'm reasonably sure this is explained in the Blue Book and certainly
in various seminal papers such as the Deutsch-Schiffman 84 paper
'Efficient implementation of the smalltalk-80 system' (http://portal.acm.org/citation.cfm?id=800542
) and the Miranda '87 paper 'BrouHaHa- A portable Smalltalk
Interpreter'.
tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
A hacker does for love what others would not do for money.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080210/676139da/attachment.htm
More information about the Squeak-dev
mailing list
|