[Vm-dev] Recreating live coding in CPython 3.5

[Jan Vrany]

On Wed, 2017-10-11 at 22:19 +0200, Nicolas Cellier wrote:
>  
> 
> 
> 2017-10-11 22:11 GMT+02:00 Jan Vrany <jan.vrany at fit.cvut.cz>:
> > On Wed, 2017-10-11 at 22:01 +0200, Nicolas Cellier wrote:
> > >  
> > >
> > >
> > > 2017-10-11 21:56 GMT+02:00 Jan Vrany <jan.vrany at fit.cvut.cz>:
> > > > On Wed, 2017-10-11 at 21:49 +0200, Bert Freudenberg wrote:
> > > > >  
> > > > > On Wed, Oct 11, 2017 at 9:32 PM, Jan Vrany <jan.vrany at fit.cvu
> > t.cz
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > > Indeed such feature is essential for live coding.  I will
> > > > have to
> > > > > > add
> > > > > > > it to my implementation thanks.
> > > > > >
> > > > > > I don't think become: is essential. Smalltalk/X for
> > instance
> > > > does
> > > > > > not
> > > > > > use #become: yet it still provides live coding (in my
> > opinion).
> > > > >
> > > > > Do you know how instances are reshaped without become in
> > > > Smalltalk/X?
> > > >
> > > > Yes, it's very simple: they are not reshaped at all :-)
> > > >
> > > > Jan
> > >
> > >  
> > > Then does that mean that
> > > - classes are not mutated, but that a new one is created, and old
> > > objects are still pointing on old classes,
> > 
> > Exactly. The old class eventually becomes (not #become:s :-)
> > garbage 
> > and gets (eventually) collected.
> > 
> > > - or that mutation is forbidden as long as instances or sub-
> > instances
> > > exist (like in Smalltalk V if I remember)
> > > - or that one may expect catastrophic consequences when
> > reshaping?
> > 
> > Depends what you call catastrophic consequences...
> > 
> > Jan
> > 
> 
> Catastrophic could be for example a buffer overflow that would bypass
> VM safety...
> Typically when instances and compiled methods idea of inst. var.
> layout divorces.
> That does not seem the case in Smalltalk/X from what you describe...
> For example, in Squeak or VW, when there is a Foo>>bar method up in
> the stack that triggers removal of an ivar, then writes into an ivar,
> boom! object memory is corrupted... 

I see. No, this should not happen in Smalltalk/X. Indeed all that 
logic implemented on Smalltalk level so one can construct code that
results in this kind of a corruption (simply change offsets in 
method's bytecode array).

To make the system robust against this sort of problems one might need 
to take the approach not unlike the one of Java (JVM) which is 
more robust w.r.t. this. This is one of the reasons (not the only one)
why "live coding" in Java is lot more complicated (but not entirely
impossible).


> Indeed the methods cannot easily be become'd while still active... So
> they are replaced - but the instances are become'd

Jan