[Glass] About GsDeployer new doBulkMigrate

[Mariano Martinez Peck]

On Wed, Apr 16, 2014 at 9:40 PM, James Foster <
james.foster at gemtalksystems.com> wrote:

> > Ahhhh of course...the migrate stuff "just" changes the class pointer of
> the instances right? So if the slots for XXX instVars were there...they
> won't get lost. I guess it is similar to Pharo's #adoptInstance: and
> #primitiveChangeClassTo:
>
> I don’t think so. Migration creates a completely new object in a different
> location, and offers the new object the chance to get data from the old
> object. By default, instance variables that are the same are copied across
> (you can override this method to do something else). After the new object
> copies whatever it wants, the system does a two-way become on the objects
> to swap the identities. (Because GemStone uses an object table, swapping
> identities is very easy.)
>
> So, it does not “just” change the class pointer, it creates an entirely
> new object with different instance variables and the old object is
> immediately eligible for garbage collection (because no one else has a
> reference to it). If the new class does not have an instance variable XXX,
> then the slot for XXX is not present in the new object; the data in that
> slot in the old object will get lost.
>
> My understanding is that this is essentially what all Smalltalks
> (including Pharo) do when you change the definition of a class: there is
> actually a new class and a scan is made through object memory finding
> instances of the old class, creating new instances of the new class,
> copying across instance variables that are shared, and making the old
> instances eligible for garbage collection. The difference with GemStone is
> that the migration is optional and the data copying can be controlled,
> while in other Smalltalks the migration is automatic and there is no
> opportunity to salvage data in instance variables that do not carry across.
> Thus, GemStone can have the same semantics as Pharo (except it takes longer
> if the object space is larger), but it can be more flexible.
>
> While the old object is eligible for garbage collection, it is unlikely to
> be lost right away and can probably be found. I have had occasion to list
> instances of the old class (they are likely still around), and salvage
> things from them.
>
> Does that make sense (or did you already understand all of this and I just
> misinterpreted you comment above!)?
>

Thanks James. Originally, I thought GemStone would do something like what
you describe here. However, after Dale's comment it made me thing of a
simply class pointer change. His comment that confused me is:   *"if for
some reason you mess up your class history, it should be possible to
rebuild the class history from the instances of the old class"    *
So....how that is possible? say old instances had a instVar XXX which new
class doesn't have. Such slot will get lost when old instances are
migrated. So...unless all old instances are still recheable, I will not be
able to rebuild/recover my original old instances. Right? So Dale's comment
is correct if only old instances are still recheable and not GCed ?

Thanks for the clarification.




-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140416/15a4ff6f/attachment.html>