[Vm-dev] InterpreterSimulator

[Clément Bera]

2016-03-15 1:23 GMT+01:00 Ben Coman <btc at openinworld.com>:

>
> On Tue, Mar 15, 2016 at 3:12 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> > Now, all the above optimization ends up recording class information in
> the inline caches which are in send sites in MCMs and each send in an MCM
> corresponds to a send bytecode in a BCM.  So what we do in Sista is add a
> primitive that answers the state of the inline caches in a BCM, in a form
> that hides the MCM reality.  Let's look at an example:
> >
> >
> > Here's a little doit:
> >
> > 1 to: 4 do: [:i| (#(1 1.0 #one 'one') at: i) class].
> >
> > It sends #<= and #+ hidden in the inlining of the to:do:.  It sends #at:
> to the array, and it sends #species to a SmallInteger, a BoxedFloat64, a
> ByteSymbol and a ByteString (I use #species, not #class because the VM
> inlines #class so there is no send if we use it).  It contains a
> conditional branch that tests the result of #<=.  Here's the bytecode:
> >
> > 57 <76> pushConstant: 1
> > 58 <68> popIntoTemp: 0
> > 59 <10> pushTemp: 0
> > 60 <22> pushConstant: 4
> > 61 <B4> send: <=
> > 62 <AC 0B> jumpFalse: 75
> > 64 <21> pushConstant: #(1 1.0 #one ''one'')
> > 65 <10> pushTemp: 0
> > 66 <C0> send: at:
> > 67 <D0> send: species
> > 68 <87> pop
> > 69 <10> pushTemp: 0
> > 70 <76> pushConstant: 1
> > 71 <B0> send: +
> > 72 <68> popIntoTemp: 0
> > 73 <A3 F0> jumpTo: 59
> > 75 <78> returnSelf
> >
> > Here's the actual object the send and branch data primitive answers for
> an execution of the above:
> >
> > {#(62 5 4).
> >    {66 . Array . (Object>>#at: "a CompiledMethod(1789611)")} .
> >    {67 . SmallInteger . (Object>>#species "a CompiledMethod(3005395)") .
> >             BoxedFloat64 . (Object>>#species "a
> CompiledMethod(3005395)") .
> >             ByteSymbol . (ByteSymbol>>#species "a
> CompiledMethod(3876413)") .
> >             ByteString . (Object>>#species "a CompiledMethod(3005395)")}
> } . '
> >
> > So what does this say?  The entry for bytecode 62 <AC 0B> jumpFalse: 75
> has been executed 5 times and taken 4 times.  We count conditional branches
> so that ofetn executed code calls back into Smalltalk to let Sista run, do
> its analysis, optimize, and continue in optimized code.
> >
> > The entry for bytecode 66 <C0> send: at: has one class, Array, and for
> that class the method invoked is Object>>#at:.
> > The entry for bytecode 67 <D0> send: species as four classes,
> SmallInteger, BoxedFloat64, ByteSymbol and ByteString, and all of them
> happen to invoke Object>>#species.
> >
> > So the realities of machine code are completely hidden form the image.
> it sees only bytecodes, and indeed it optimizes to bytecodes.  Only the JIT
> converts those bytecodes to machine code, and it hides the details, mapping
> back all the infrmation into the portable machine-independent bytecode
> representation.
> >
>
> Just naive curiosity, why don't you count the number of times each
> class is a receiver, similar to the branch?  IIUC the PIC is
> essentially a case statement, and you might order the more frequent
> receiving class earlier in the case statement?
>

Yes, in fact we are thinking of doing that.

The problem is that counters induces overhead in non optimized code, and
that overhead can't be too high. Once the optimizer is more efficient, we
could allow more overhead and do this kind of things.

For PIC it would be nice to detect cases taken only once.

>
> cheers -ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160315/106b4104/attachment-0001.htm