[Vm-dev] becomeForward: and survival...
Henrik Sperre Johansen
henrik.s.johansen at veloxit.no
Mon Jan 14 13:52:02 UTC 2013
On 11.01.2013 20:14, Eliot Miranda wrote:
> 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:.
Don't think that's a problem unique to Newspeak, if the comment at the
bottom of ClassBuilder>>update:to: is to be trusted :)
> 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?
Can't think of anything for 1, barring any bugs marking active objects
as freed of course.
Which isn't very likely, as long as one doesn't introduce a destroy()
primitive, but keep the transition to free status an internal detail of
Out of curiosity, are there other places than becomeForward: this is
For 2, I agree with becomeForward: "freeing" the forwarded objects.
I don't quite see the value in the preferred method from the comment
other than that it *could* be implemented in the image (creating copy of
class before forwarding that, and change class of forwarded instances to
that) , it just sounds like a lot of work for no real benefit
considering the whole point is to avoid the instances being referrable
Not to mention, that would only help in the specific
ClassBuilder/AtomicInstaller case, and not in a general becomeForward ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev