[Vm-dev] Recreating live coding in CPython 3.5

[Nicolas Cellier]

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.cvut.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... Indeed the methods cannot easily be become'd
while still active... So they are replaced - but the instances are become'd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171011/40a336be/attachment.html>