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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Aug 31 23:33:47 UTC 2016


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...
Beware: don't you modify the layout of one superclass...

2016-09-01 1:17 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> Due to read only ClassBinding it would be just a little bit more hackish:
>
> (Smalltalk globals associationAt: #SystemProgressMorph) instVarAt: 2 put:
> SystemProgressMorph copy.
>
> 2016-09-01 1:12 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>> Or would this even more simple hack work? Put in the preamble something
>> like:
>>
>> Smalltalk at: SystemProgressMorph put: SystemProgressMorph copy.
>>
>> This way, the old instances should not be mutated...
>>
>> 2016-08-24 7:06 GMT+02:00 marcel.taeumel <Marcel.Taeumel at hpi.de>:
>>
>>> marcel.taeumel wrote
>>> >
>>> > Bert Freudenberg wrote
>>> >> On Tue, Aug 23, 2016 at 11:21 AM, marcel.taeumel &lt;
>>>
>>> >> Marcel.Taeumel@
>>>
>>> >> &gt;
>>> >> wrote:
>>> >>
>>> >>>
>>> >>> Hi, there.
>>> >>>
>>> >>> It is, unfortunately, not possible to turn back time and rewrite
>>> >>> history.
>>> >>> ;-)
>>> >>>
>>> >>
>>> >> ... unless we're dealing with software. Oh wait, we are ;)
>>> >>
>>> >> There is several important code that makes excessive use of instVar
>>> >>> accesses such as in SystemProgressMorph or HandMorph. Making any
>>> change
>>> >>> in
>>> >>> their class layout while using some of their methods will provoke a
>>> >>> strange
>>> >>> error. This could only be changed by a VM that keeps old class
>>> >>> layouts/schemata around for some longer time until there is no old
>>> >>> compiled
>>> >>> method on any stack anymore.
>>> >>
>>> >>
>>> >> Class layout changes and instance migration is handled fully in the
>>> image
>>> >> by class ClassBuilder. The VM is not at fault here.
>>> >>
>>> >>
>>> >>> Usually, restarting the update process helps here. There is no way to
>>> >>> fix
>>> >>> that in order to interactively update from 5.0 to 5.1 without any
>>> >>> errors.
>>> >>>
>>> >>
>>> >> We can retroactively change the config map that introduced the
>>> problem.
>>> >> I'm
>>> >> certain it would be possible to fix, but I am not entirely sure it's
>>> >> worth
>>> >> the trouble.
>>> >>
>>> >> - Bert -
>>> > Hi Bert,
>>> >
>>> > the config map will not help, we would have to change numerous MCZs
>>> since
>>> > point X in time to rewrite history. :) "Oh, would we have always been
>>> > using accessors here instead of instVar accessess..."
>>> >
>>> > Best,
>>> > Marcel
>>>
>>> ...even then, how do you update the code in image Y, which is going to be
>>> updated before it is updated? This is not even possible for every user's
>>> images out there... :-/
>>>
>>> The Java Hotspot VM has a mapping table for changed instVar accesses.
>>> Maybe
>>> we could use this trick, too? Still, would only applies to future
>>> versions.
>>> We cannot rewrite history because it is not only one piece of software
>>> in a
>>> single version control system with a single version checked out. :)
>>>
>>> Best,
>>> Marcel
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://forum.world.st/Re-Does-
>>> anyone-recognize-this-glitch-in-our-trunk-update-processing-
>>> was-Vm-dev-buildspurtrunkvmmaker-tp4912130p4912403.html
>>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160901/eff792b8/attachment-0001.htm


More information about the Squeak-dev mailing list