[squeak-dev] Re: Does anyone recognize this glitch in our trunk update processing? (was: [Vm-dev] buildspurtrunkvmmakerimage.sh fails on Mac)

Bert Freudenberg bert at freudenbergs.de
Thu Sep 1 09:41:30 UTC 2016

On Thursday, 1 September 2016, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> The copy is not completely clean because this assertion then fails:
> (SystemProgressMorph superclass subclasses detect: [:e | e name =
> #SystemProgressMorph]) == SystemProgressMorph
> IOW, the superclass is still pointing to the old class, so any change to
> superclass layout won't propagate to the new subclass... Bad.
> But there's also this possibility:
> | oldClass |
> oldClass := SystemProgressMorph copy become: SystemProgressMorph.
> SystemProgressMorph allInstancesDo: [:e | oldClass adoptInstance: e].
> We mutate all the instances to a class detached from Smalltalk and immune
> to some changes...

This is an interesting idea.

Basically we want to prevent the existing instances to be migrated to the
new class layout when we change the instance variables. One way is what
Nicolas suggests, but another would be to just keep the migration from
happening in the first place, in ClassBuilder.

Could this be a general approach? To never migrate instances that are
receivers of a context? They  would still be instances of the old (now
obsolete) class version. They could even be kept in a weak array to be
migrated later, once the contexts are no longer active. The processes could
even be restarted
to get rid of these contexts.

There are other Smalltalks (e.g. GemStone) that even allow different class
versions to exist side-by-side. We do have class versions too, but they
have only been used for migrating serialized instances when the instance
variables did *not* change (which is how the need for migration is normally
detected). Hmm, maybe that is actually irrelevant, just ran through my mind

So what do you think about delayed migration of instances on the stack?

- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160901/6cfda2d3/attachment.htm

More information about the Squeak-dev mailing list