[Vm-dev] Recreating live coding in CPython 3.5

[Jecel Assumpcao Jr.]

Dimitris,

>  unfortunately no, those articles focus on JIT compilation and
> method lookups and not live coding. 

Actually, these things are at the very core of live coding. Unless we
are using the term in very different ways. So let me explain what I mean
by "live coding".

Imagine that I have two code browsers showing methods like:

methA: x
...
 [...] whileTrue: [ self methB ].
...

and

methoB
...
...


and I have a third window where I am watching the effect of running
#methA. What happens if I change the text in the second window and
select "accept"? What happens if I edit the first window and accept?

If the system is a simple interpreter and "accept" generated new
bytecodes that get installed in the method dictionary in place of the
previous version of the method, we would expect an instant change in
behavior when changing #methB but nothing would happen when #methA is
modified. That is because #methB is repeatedly called and the current
execution finishes executing using the old code and then it gets invoked
again and starts executing the new code. #methA, on the other hand, is
in the middle of a very long loop and will keep executing the old code
(pointed to from the stack) even though the method dictionary now has
new code.

An alternative system could use #become: to replace bytecodes when
changing a method, but that would be hard to do (suddenly the stack
state would no longer make sense with the new bytecodes) and would be
harder for the user to understand. So let's not go there.

If we have a JIT and not a simple interpreter, things can be complicated
if we want to keep the same semantics. The compiler might have inlined
#methB into #methA and in that case changing #methB would no longer have
a visible effect in the third window. The technology to make it work as
expected is called "dynamic deoptimization" and is pretty sophisticated.

-- Jecel