[Vm-dev] becomeForward: and survival...

[Eliot Miranda]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130111/8c51dd36/attachment.htm