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

[Henrik Sperre Johansen]

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?
> -- 
> TIA,
> Eliot
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 
the vm.
Out of curiosity, are there other places than becomeForward: this is 
applicable?

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 
afterwards.
Not to mention, that would only help in the specific 
ClassBuilder/AtomicInstaller case, and not in a general becomeForward -> 
allInstances scenario.

Cheers,
Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130114/958c8add/attachment.htm