Thanks!
We will probably address that in Pharo 40. I do not know if esteban cherrypicked this changes.

Stef

> The global GC here is pretty unfortunate.  It is there because the VM used to leave old instances lying around.  It works like this:
> 
> we want to reshape instances of class C, e.g. by adding an inst var, and so
> 
> 1. create C', which is C plus an inst var
> 2. create a parallel set of instances of class C', one for each instance of class C
> 3. for each corresponding pair of instances copy state from the instance of C to the instance of C'
> 4. forward-become the instances of C to the instances of C' (now no references to the instances of C remain)
> 5. become C to C' (now C' is the new C)
> 
> The bug is that the old instances of C are still in the heap.  Because of the become in 5. they look like instances of the new C, but are the wrong size; they lack space for the new inst var.  They're not reachable (4. replaced all references to them with references to the instances of C') but they can be resurrected through allInstances (someInstance,nextInstance) which works not by following references from the roots (Smalltalk and the activeProcess) but by scanning objects in the heap.
> 
> However, this was "fixed" in
> 
> 	Name: VMMaker.oscog-eem.254
> 	Author: eem
> 	Time: 11 January 2013, 7:05:37.389 pm
> 	UUID: 74e6a299-691e-4f7d-986c-1a7d3d0ec02c
> 	Ancestors: VMMaker.oscog-eem.253
> 
> 	Fix becomeForward: so that objects whose references are deleted are
> 	freed and can no longer be resurrected via allObjects or allInstances.
> 
> The change is to free the objects replaced in a forwardBecome so they are no longer objects (effectively their class is null (not nil, but 0)).  So they can't be resurrected and hence the global GC is un necessary.  The Newspeak folks, in particular Ryan Macnak, spotted this and encouraged me to make the change.  It of course speeds up instance mutation considerably.
> 
> I say fixed because there was a bug tail:
> 
> 	Name: VMMaker.oscog-eem.258
> 	Author: eem
> 	Time: 18 January 2013, 11:01:23.072 am
> 	UUID: da1433f1-de50-475f-be33-f462b300a2ea
> 	Ancestors: VMMaker.oscog-eem.257
> 
> 	Fix becomeForward: when the rootTable overflows.  There were two
> 	bugs here.  One is that initializeMemoryFirstFree: used to clear the
> 	needGCFlag so if the rootTable overflowed noteAsRoot:headerLoc:'s setting of the needGCFlag would be undone after the sweep.
> 	The other is that rootTable overflow was indicated by
> 	rootTableCount >= RootTableSize which could be undone by
> 	becomeForward: freeing roots which need to be removed from
> 	the rootTable.  At some point in becomeForward the rootTable would
> 	fill but at a later point a root would be freed, causing the table to
> 	become not full.
> 
> 	The fix is two fold.  1. Add an explicit rootTableOverflowed flag
> 	instead of relying on rootTableCount >= RootTableSize.
> 	2. move the clearing of the needGCFlag to the GC routines.
> 	Remove unnecessary senders of needGCFlag: false, and remove
> 	the accessor.
> 
> 	Name: VMMaker.oscog-eem.255
> 	Author: eem
> 	Time: 12 January 2013, 6:28:41.398 pm
> 	UUID: 51e53ec1-8caf-41f6-9293-1088ef4b82d8
> 	Ancestors: VMMaker.oscog-eem.254
> 
> 	[New[Co]]ObjectMemory:
> 	Fix freeing of objects for becomeForward:.  Remove freed young
> 	roots from the rootsTable.  Filter freed objects pointet to from the
> 	extraRootsTable (because these locations can change it is wrong
> 	to remove entries from the extraRootsTable).
> 
> But the bottom line is that, at least on the current Cog VM, that global GC is unnecessary.  David, Tim, this still needs to be folded into ObjectMemory in the standard interpreter. But doing so is very worth-while.  Monticello loads are noticeably faster.
> 
>> KR
>> Phil 
>> 
>> 
>> -- 
>> Best regards,
>> Igor Stasenko.
> 
> 
> Eliot (phone)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140326/ff206fee/attachment.htm