Hi Dan --

Wrt your first optimization ... The SCHEME guys used similar arguments in 
one or more of the SCHEME papers to show that there are many cases in which 
no stack has to be allocated or popped (so a simple goto in the code will 
do the job). Someone on the Squeak list probably has a reference to the 
paper or papers I'm talking about. Sounds like a good idea, and should work 
pretty well. The second idea sounds like it should work very well also.

Cheers,

Alan

At 06:11 AM 3/22/2006, 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