becomeForward: and survival...

Hi All,

    there's an interesting issue with becomeForward: that's raised by the Newspeak implementation. Its AtomicInstaller, the equivalent of ClassBuilder that mutates existing instances when classes are redefined, uses forwardBecome: to map old instances to new instances.  But it uses allInstances subsequently to collect the modified instances a second time.  Since becomeForward: currently simply manipulates references, the old instances no longer referenced after becomeForward: can still be found by allInstances, and this causes a bug in AtomicInstaller, which is worked-around by running the GC immediately after the forwardBecome:.

Gilad Bracha's desire is for becomeForward: to eliminate the objects whose references are replaced.  My initial reaction was to say don't redefine becomeForward: by requiring it to run a GC; the existing primitives are useful as defined and a more complex operation that also eliminates objects rather than just replacing references can be defined by composition.  But that's because I'm stupid.

It strikes me that its really easy in the current GC for becomeForward: to mark the objects in the second array, the objects whose references are eliminated, such that they would not be discovered via allInstances or allObjects.  In the Squeak GC the objects are merely freed.  My concern is with some future GC.  I'm fairly confident that the same could be implemented in any GC; that one can enumerate a given set of objects without running a full GC and mark each object such that it is effectively removed from the heap, prior to running the GC, and that the space occupied will be reclaimed at some later time.

So I have two questions.

1.  anyone think of a convincing counterexample of a GC in which that wouldn't be possible?

2.  anyone have an opinion or argument either way that becomeForward: should free the objects whose references it destroys instead of merely destroying those references?

--
TIA,

Eliot