Complexity and starting over on the JVM (ideas)

Michael van der Gulik mikevdg at gmail.com
Sun Feb 10 23:41:15 UTC 2008


On Feb 11, 2008 12:29 PM, tim Rowledge <tim at rowledge.org> wrote:

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


Oh - that's what he meant by a linear stack - stack frames are contiguous in
memory.

Gulik.


-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080211/3a99d99f/attachment.htm


More information about the Squeak-dev mailing list