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