Hi

I wanted to know how this was relating to the way VW treats blocks:  
clean block [:each | each zork], copy blocks and full blocks.
Does anybody able to compare?

Stef


On 22 mars 06, at 15:11, Dan Ingalls wrote:

> Hi -
>
> I've got my little Squeak in Java running (hope to send out a link  
> soon), and I've been pondering how to make it run faster.  In the  
> process, I've thought of two techniques, one of which is new (to  
> me) and the other occurred to me years ago, but I never tried it out.
>
> Since neither would really be all that hard to do in Squeak, I  
> thought I'd mention them here for those folks who delight in such  
> things, and with the further hope that someone might actually try  
> them out.
>
>
> Lazy Activation
> This was the next thing I was going to do for Apple Smalltalk back  
> when I got drafted to the hotel business back in 1987.  The essence  
> of the idea is that the purpose of activating a context is to save  
> the execution state in case you have to do a send and, conversely,  
> you don't really need an activation if you never need to do a real  
> send.
>
> I had a lot of fun instrumenting the VM to figure out just how many  
> activations could be avoided in this way, and my recollection is  
> that it was roughly 50%.  I believe the statistics were better  
> dynamically than statically, because there are a lot of methods  
> that, in general need to be activated, but they may begin with a  
> test such as
> 	position > limit ifTrue: [^ false]
> and for every time that this test succeeds, you can get away  
> without ever needing an activation.
>
> But, you say, you still need a pointer to the method bytes and a  
> stack frame, and this is true, but you don't need to allocate and  
> initialize a full context, nor to transfer the arguments.  The idea  
> is that, when you hit the send, you do the lookup, find the method,  
> and then jump to a *separate copy* of the interpreter that has  a  
> different set of bytecode service routines.  For instance,  
> 'loadTemp' will, depending on the argument count, load from the  
> stack of the calling method (which is still the "active" context).   
> 'Push', since there is no allocated stack, pushes into a static  
> array and, eg, 'plus' does the same old add, but it gets its args  
> from the static array, and puts its result back there.  And if  
> anything fancy, such as a real send, does occur, then a special  
> routine is called to do a real activation, copy this static state  
> into it appropriately, and retry the bytecode in the normal  
> interpreter.
>
> It's probably worth confirming the results that I remember, but I  
> wouldn't be surprised if one could almost double the speed of  
> Squeak in this manner.
>
>
> Cloned Activation
> This one I just thought of, but I can't believe someone hasn't  
> already tried it, either in squeak or some similar system.  The  
> idea here is to provide a field in the method cache for an extra  
> copy of a properly initialized context for the method (ie, correct  
> frame size, method installed, pc and stack pointer set, etc).   
> Then, when a send occurs, all you have to do is an array copy into  
> blank storage, followed by a short copy of receiver and args from  
> the calling stack.
>
> There's a space penalty for carrying all the extra context  
> templates, of course, but I think it's not unreasonable.  Also, one  
> could avoid it for all one-time code by only allocating the extra  
> clone on the second call (ie, first call gets it into the method  
> cache; second call allocates clone for the cache).
>
> I have little sense of how much this might help these days -- I  
> haven't looked in detail at the activation code for quite a while.  
> Obviously the worse it si right now, the more this technique might  
> help.
>
>
> Mainly I just like to think about this stuff, and it occurred to me  
> that, if someone were looking for a fun experiment or two, it might  
> turn out to have some practical value.  I haven't looked at Exupery  
> to know whether these things are already being done, or whether  
> they might fit well with the other techniques there, but I'm sure  
> Bryce could say right off the bat.
>
> 	- Dan
>