Hi Anthony,

[Note: cc-ing Squeak-dev since some other VM hackers might want to chime in
here]

I've been recently (as in: today ;) been reminded that we should really make
use of the new block closures (for which primitive support will be in any
new VMs as they are part of VMMaker-3.6). IIRC, then only significant
downside is activation speed which - according to your notes - was at about
half of what using BlockContexts were today.

So what ways do we have to bring their activation speed closer to the speed
of block activation today? I don't know if you've done any exhaustive
measures to figure out where the time actually goes but my feeling is that
there is a good chance that we may be overlooking something in general
activation speed. Question: Do you have any feeling whatsoever, where the
additional time is spent? Is is just context allocation? Somehow I don't
quite think this would be the case as we should be pretty good with the
context recycling here. Any other ideas where time is spent, what we may be
able to short-cut specifically for block (as opposed to: general method)
activation?

One thought that occured to me is that there's some potential that the byte
codes for #value/#value: could make some difference. This may not be much
but there's definitely some overhead here so we may consider to make those
bytecodes support closure activation instead of optimizing for BlockContexts
as they do today - in particular as this would allow us to use the
#internalXYZ variants for activating the closure, which would get inlined
into the VM, etc. etc. etc.

If you have any thoughts on this I'd be delighted to hear them. Making the
closures as fast (or very close to) what we have in BlockContexts today
would be a great step forward for (finally) getting true closures to work in
Squeak. And perhaps be a perfect little project for 3.7alpha ;-)

Cheers,
  - Andreas