<div dir="ltr">Thanks for the answer it was very helpful. I got it now.<div><br></div><div>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 <a href="http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/" target="_blank" style="font-size:13px;font-family:arial,sans-serif">Under Cover Contexts and the Big Frame-Up</a> and I think I should read all your blog. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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 ?</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/30 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><a href="http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/" target="_blank">http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/</a>Hi Clément,<br>
<br><div class="gmail_quote">On Mon, Jul 29, 2013 at 1:54 AM, Clément Bera <span dir="ltr"><<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Hello guys,<div><br></div><div>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.</div>
<div><br></div><div>- 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 ?</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>So IMO while the hybrid CompiledMethod isn't ideal it is acceptable, having important advantages to go along with its disadvantages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>- 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.</div>
</div></blockquote><div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div>- 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 ?</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div>Thank you for any answer.</div></div></blockquote></div><br>You're most welcome. Have you read my blog post on the design? It is "<a href="http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/" target="_blank">Under Cover Contexts and the Big Frame-Up</a>", with additional information in "Closures Part I" & "<a href="http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecodes/" target="_blank">Closures Part II – the Bytecodes</a>".<br>
-- <br>best,<div>Eliot</div>
<br></blockquote></div><br></div>