[Vm-dev] Register allocation and debugging in Squeak

[Eliot Miranda]

Hi Clément,


On Tue, Aug 13, 2013 at 5:28 AM, Clément Bera <bera.clement at gmail.com>wrote:

>
> Hello Eliot and all,
>
> Recently I watched a video of Eliot introducing Cog (
> http://www.youtube.com/watch?v=-ei1bnLHdhA part 1 to 7).
>
> At some point, Eliot says that a better code generator was planned with
> optimizations such as constant folding and stack to register mapping (I
> guess it does exist, but as a prototype only).
>

This is actually the production JIT.  It is called
StackToRegisterMappingCogit.  It performs the following optimizations:

- 0 and 1 argument methods pass their receiver and argument in registers;
Those 0 and 1 argument primitives that the JIT compiles access their
arguments from registers (e.g. at: and SmallInteger and Float arithmetic).

- certain methods when compiled don't build a frame, e.g. Point>>setX:Y:
(this is new as of this week :-), [:arg| arg], [:a! :a2| a1 == a2]).

- code is not generated until bytecodes that consume operands are
encountered (this is the major optimization).  During compilation operands
are pushed onto a simulation stack, and bytecodes that consume operands can
then analyse their operands when generating code, in many cases avoiding
pushing their operands onto the stack.  e.g.
    - 0 and 1 argument sends assign their receiver and argument to
registers, avoiding the stack altogether
    - special selector arithmetic and comparison can avoid detagging
literal integer operands, and avoid reifying the results of comparison
operations to true and false if followed by a conditional branch bytecode
    - inst var stores can avoid a store check if the value assigned is a
SmallInteger literal
    - arithmetic constant-folding is done provided that the expression
starts with a literal (e.g. the Cogit will collapse 1 + 2 + var to 3 + var,
but won't collapse var + 1 + 2 to var + 3)
    - some dead code is eliminated (e.g. all code following true ifTrue:
[^1]. is removed)


However, it seems that this last optimization (register allocation) is
> tricky to manage with the debugger: in the Self VM, it seems that the
> contexts were in read-only in the debugger because they didn't know if the
> variable was stored in a register or in the memory.
>
> Now I know that Eliot wouldn't have planned an optimization that will
> destroy the debugging power of Squeak. How did you guys plan to add the
> register allocation without destroying the debugging power of Squeak ?
>
> Did you plan to add something similar to the scope descriptor that they
> have in the Self VM to allow aggressive optimizations with regular
> debugging ? Did you plan to annotate the stack frames with meta data and if
> so, how would you have implemented it ?
>

Clément, I have plans (and God is doubtless amused) but nothing in
progress.  If you're interested on doing work here then let me know and
perhaps we could skype sometime soon to discuss?

Thanks for any answers,
>
> Clement
>

Others have referenced dynamic deoptimization.  +1.
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130814/9e997197/attachment.htm