�� what you describe is how Peter Deutsch designed closures for ObjectWorks 2.4 & ObjectWorks 2.5, whose virtual machine and bytecode set served all the way through VisualWorks 3.0. �If you read the context management paper you'll understand why this is a really slow design for a JIT. �When I replaced that scheme by one essentially isomorphic to the Squeak one the VM became substantially faster; for example factors of two and three in exception delivery performance. �The description of the problem and the performance numbers are all in the paper. �There are two main optimizations I performed on the VisualWorkas VM, one is the closures scheme and the other is PICs. �Those together sped-up what was the fastest commercial Smalltalk implementation by a factor of two on most platforms and a factor of three on Windows.

I'm sorry it's complex, but if one wants good performance it's a price well-worth paying. �After all I was able to implement the compiler and decompiler within a month, and Jorge proved at INRIA-Lille that I'm far form the only person on the planet who understands it. �Lispers have understood the scheme for a long time now.

Eliot

On Thu, Mar 24, 2011 at 6:01 PM, Toon Verwaest <toon.verwaest@gmail.com> wrote:

I can't say that i clearly understood your concept. But if it will
simplify implementation
without seemingly speed loss, i am all ears :)

test
� �|b|
� �[ |a|
� � �a + b ]

Suppose you can't compile anything away, then you get

|==============
|MethodContext
|
|a := ...
|==============
� � ^
� � |
|==============
|BlockContext
|
|b := ...
|==============

And you just look up starting at the current context and go up. Except if the var is from the homeContext, then you directly follow the home-context pointer.
Since all contexts link to the home-context, this makes it 1 pointer indirection to get to the method's context. 1 for the parent context. So that makes only 2 indirections starting from the 3 nested block (so when you have [ ... [ ... [ ... ] ... ] ... ]; where all of them are required for storing captured data. ifTrue:ifFalse: etc blocks obviously don't count. And blocks without shared locals could be left out (although we might not do that, for debugging reasons).

Hope that helps.

cheers,
Toon