<div dir="ltr"><div>Hi,</div><div><br></div><div>There is no such thing as escape analysis. There is no such a thing as materializing context on demand, what we have is married context which are materialized upon divorce (typically, store into the context).<br></div><div><br></div><div><div>At BlockClosure allocation time Cog allocates a Context object, enough to hold context contents, but set only dead context available fields (args, method, receiver, etc). The context is at this point married to a frame. All accesses to contexts are caught by the VM, and if the context is still married to the frame, the frame is read instead of the context, while the frame-context divorces if the context is written. Upon divorce the context fields are set, the context become single, single contexts are normal objects. If the frame dies (return), the context is then a dead context and only fields written at creation time are available. The tricky bit is to check wether a married context refers to a frame its married to, or to random data on stack. Upon return frame do not mark the context as dead (cost too much execution time while context almost never access their frame). Context are accessed, aside from reflective API, debugging and so on, only for non local returns, which needs to check if the married frame is still alive or not. If you want to go deeper in that topic, read the 2 blog posts of Eliot on context/frame wedding/divorce.</div></div><div><br></div><div>What you are describing, with escape analysis, is performed other Smalltalks in the bytecode compiler. The idea is that a context is marked as clean (no escaping var, no non local return), copying (no non local return) or full (a non local return is present). In this case, clean blocks do not require any allocations, copying block never require their outerContext and full block do. That speeds up execution, but forbids some uncommon debugging operations. Clean blocks also mess up closure identity.</div><div><br></div><div>Closures are always allocated, except if through inlining you can prove they don't escape in the sista JIT.</div><div><br></div><div>Best!</div><div><br></div><div class="gmail_quote"><div dir="ltr">On Fri, Jan 4, 2019 at 6:11 PM Fabio Niephaus <<a href="mailto:lists@fniephaus.com">lists@fniephaus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr">Hi all,<div><br></div><div>I'm trying to understand when the outerContext of a BlockClosure is materialized in Cog. I'm assuming Cog does much better than materializing the context at allocation time of the BlockClosure, but I wasn't able to find that out by browsing VMMaker code.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Example: In `BlockClosureTest>>#setUp`, a BlockClosure is stored in an inst var and then accessed later in some tests. Assuming contexts are only materialized when necessary, how does Cog determine that the context of this closure has escaped? In the previous example, thisContext is also stored in an inst var. Whenever a context is stored like this, we must consider it escaped. Does the same apply for closures? As in, must we consider their home context escaped as soon as closures are stored somewhere?</div><div><br></div><div>Cheers,</div><div>Fabio</div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span style="font-size:12.8px">Clément Béra<br></span><span style="color:rgb(0,0,238)"><a href="https://clementbera.github.io/" target="_blank">https://clementbera.github.io/</a></span><div style="font-size:12.8px"><a href="https://clementbera.wordpress.com/" target="_blank">https://clementbera.wordpress.com/</a></div></div></div></div></div></div></div>