[Vm-dev] Eliot's BlockClosure model questions

Clément Bera bera.clement at gmail.com
Tue Jul 30 20:56:36 UTC 2013

Thanks for the answer it was very helpful. I got it now.

I had a look at the first posts of your blog (Closures I & II) when I was
working on the Opal compiler. Today I was looking at Under Cover Contexts
and the Big Frame-Up<http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/>
I think I should read all your blog.

That is really nice that you wrote this blog it is the main documentation
about an efficient Smalltalk VM. I learnt by looking at Cog's source
mostly. VW VM source is closed so... I will have a look at Strongtalk
implementation instead it seems it is open source.

Why are the clean blocks of VW much faster ? Are they activated like method
? I didn't find it in your blog (probably because it is not in Cog). Is it
possible to implement clean blocks in Pharo/Squeak ? (I think that 53% of
blocks non optimized by the compiler are clean in Pharo 3) Would it worth
it ?

2013/7/30 Eliot Miranda <eliot.miranda at gmail.com>

> http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/Hi Clément,
> On Mon, Jul 29, 2013 at 1:54 AM, Clément Bera <bera.clement at gmail.com>wrote:
>> Hello guys,
>> I was looking recently at the blockClosure model of Eliot in Pharo/Squeak
>> and the blockClosure model of VisualWorks and I have a few questions.
>> - Why Pharo/Squeak does not have compiled block as in VW and has the
>> block byte code in the enclosing method ? Is it to save memory ? Would it
>> worth it to implement CompiledBlock in term of speed and memory consumption
>> ?
> Squeak derives directly from the "blue book" Smalltalk-80 implementation
> in which CompiledMethod is a hybrid object, half pointers (method header
> and literals) and half bytes (bytecode and source pointer).  This format
> was chosen to save space in the original 16-bit Smalltalk implementations
> on the Xerox D machines (Alto & Dorado).  VisualWorks has a few extra steps
> in between,  In ObjectWorks 2.4 and ObjectWorks 2.5 Peter Deutsch both
> introduced closures and eliminated the hybrid CompiledMethod format,
> introducing CompiledBlock.
> IMO adding CompiledBlock, while simplifying the VM a little would not
> improve performance, especially in the interpreter, essentially because
> activating and retuning form methods now requires an ecxtra level of
> indirection to get from the CompiledMethod object to its bytecodes in its
> bytecode object.
> However, adding CompiledBlock (or rather eliminating the hybrid
> CompiledMethod format) would definitely *not* save space.  The hybrid
> format is more compact (one less object per method).  One can try and
> improve this as in VisualWorks by encoding the bytecodes of certain methods
> as SmallIntegers in the literal frame, but this is only feasible in a pure
> JIT VM.  Squeak still has an interpreter, and Cog is a hybrid JIT and
> Interpreter.  In an interpreter it is costly in performance to be able to
> interpret this additional form of bytecodes.
> So IMO while the hybrid CompiledMethod isn't ideal it is acceptable,
> having important advantages to go along with its disadvantages.
>  - Why Pharo/Squeak context have this variable closureOrNil instead of
>> having the closure in the receiver field as in VW ? Is it an optimization
>> because there are a lot of access to self and instance variables in the
>> blocks in Pharo/Squeak ? Because if I'm correct it uses 1 more slot per
>> stack frame to have this.
> I did this because I think its simpler and more direct.  I don't like VW's
> access to the receiver and inst vars having to use different bytecodes
> within a block to within a method.  There are lots of complexities
> resulting from this (e.g. in scanning code for inst var refs, the
> decompiler, etc).
> But in fact there isn't really an additional stack slot because the frame
> format in the VM does not use the stacked receiver (the 0'th argument) as
> accessing the receiver in this position requires knowing the method's
> argument count.  So in both methods and blocks the receiver is pushed on
> the stack immediately before allocating space for, and nilling, any
> temporaries.  This puts the receiver in a known place relative to the frame
> pointer, making it accessible to the bytecodes without having to know the
> method's argument count.  So the receiver always occurs twice on the stack
> in a method anyway.  In a block, the block is on the stack in the 0'th
> argument position.  The actual receiver is pushed after the temps.
> - Lastly, does VW have the tempVector optimization for escaping write
>> temporaries in their blockClosure ? It seems they have not (I don't see any
>> reference to it in VW 7). Did Pharo/Squeak blocks earns a lot of speed or
>> memory with this optimization ?
> Yes, VW has this same organization.  I implemented it in VisualWorks 5i in
> ~ 2000.  It resulted in a significant increase in performance (for example,
> factors of two improvement in block-intensive code such as exception
> handling).  This is because of details in the context-to-stack mapping
> machinery which mean that if an activation of a closure can update the
> temporaries of its outer contexts then keeping contexts and stack frames in
> sync is much more complex and costly.  The 5i/Cog organization (which in
> fact derives from some Lisp implementations) results in much simpler
> context-to0stack mapping such that no tests need be done when returning
> from a method to keep frames and contexts in sync.
>> Thank you for any answer.
> You're most welcome.  Have you read my blog post on the design?  It is "Under
> Cover Contexts and the Big Frame-Up<http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/>",
> with additional information in "Closures Part I" & "Closures Part II –
> the Bytecodes<http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecodes/>
> ".
> --
> best,
> Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130730/c1597a72/attachment.htm

More information about the Vm-dev mailing list