[Glass] About GsDeployer new doBulkMigrate

[James Foster]

On Apr 16, 2014, at 5:56 PM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:

> 
> 
> 
> 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. 

Dale’s comment is an accurate description of rebuilding a ClassHistory, while you are asking about recovering data from a migrated instance.

GemStone provides a way to group versions of a class into a ClassHistory, a subclass of Array. By default, when you create a new version of a class it gets added to the ClassHistory of the old version. If you do a lot of refactoring (and Smalltalkers should be doing this, right!?), then a ClassHistory can get large. If there is no reason to keep the old class versions, then you can remove a Class from a the ClassHistory. Sometimes I get a bit too aggressive in my housecleaning and discover that I prematurely removed something that I should have saved a bit longer, and thus I’ve “messed up my class history.” (Actually, Dale might have had me in mind when he said this. He knows, and teases me periodically, about my habit of deleting things that I think I won’t need. I periodically have to go to him and ask him to resend an email that I prematurely deleted!)

So, to rebuild a ClassHistory, you find the classes, add them to a new ClassHistory, and then add the ClassHistory to the class. How do you find the classes? if you haven’t migrated all the instances, then when you stumble across an old instance you can ask it for its class. If it doesn’t share a ClassHistory with the class you want to migrate to, then you probably have to “rebuild the class history” (as Dale suggests).

If you no longer have a reference to an old instance, but believe it is still out there (not yet garbage collected), then you can find the instances of a class by using the #’allInstances’ method on the old Class. If you don’t have a reference to the old Class you can try #’allInstances’ on Metaclass3. 

So, Dale was talking about rebuilding a ClassHistory, which can be done (I’ve done it many times). As to your question about old instances, as long as they are not GCed, then you can still get them using the #’allInstances’ methods discussed above.

James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140416/7b6b58be/attachment.html>