[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:12:00 UTC 2016


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/d006fc8d/attachment.htm


More information about the Squeak-dev mailing list