[Vm-dev] Materializing BlockClosure's outerContext?

Clément Béra bera.clement at gmail.com
Fri Jan 4 18:23:24 UTC 2019


Hi,

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).

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.

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.

Closures are always allocated, except if through inlining you can prove
they don't escape in the sista JIT.

Best!

On Fri, Jan 4, 2019 at 6:11 PM Fabio Niephaus <lists at fniephaus.com> wrote:

>
> Hi all,
>
> 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.
>

> 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?
>
> Cheers,
> Fabio
>


-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190104/5b0fba02/attachment.html>


More information about the Vm-dev mailing list