[self-interest] Re: GC (was... something else)

David Ungar David.Ungar at Eng.Sun.COM
Sun Jun 27 05:46:07 UTC 1999


Mario has probably already said this, but in case not,
you are right, but roots are also found by scanning the stacks.

  - Dave


At 9:28 AM -0300 6/25/99, Douglas Atique wrote:
>So, there are objects that can't be garbage collected because 
>primitives depend on them.
>In fact, the objects you mentioned, true, false, nil, etc. are part 
>of the language
>definition, instead of simple objects. If they are destroyed, the 
>language loses part of
>its semantics. But for the user objects, those that don't play a 
>special role in
>implementing the language definition, the root is still the lobby. Am I right?
>There is more below.
>
>Douglas
>
>mario at Eng.Sun.COM wrote:
>
>> > Ain't this a bit strange? I mean, if I (a Self programmer) 
>>remove all references to
>> > an object (and I guess for us Self programmers the lobby is THE 
>>root) by removing
>> > it from the lobby, shouldn't the VM garbage collect the object?
>>
>> What I'm saying is that the lobby is not the only root, nor can it
>> be.  All those other objects have to exist too.  For example, there
>> has to be a true object because you can write 1 _Equals: 1 and the VM
>> has to return _something_.
>
>If one performs the destructive process I did, of removing all slots 
>from the lobby,
>theoretically, one should end with a useless world because nothing 
>could be typed in the
>prompt, besides self, that would match any slot in any accessible 
>object. But with
>primitives one can reconstruct everything (at least from the initial 
>empty world) by
>recovering objects from the objectIDArray.
>If primitives were method slots of a special system object, then 
>these objects on which
>primitives depend could be referenced by slots on this system 
>object. But this doesn't
>eliminate the problem that one comes and _RemoveSlot: from this 
>object until it
>degenerates into an empty object, unless the slots are hardwired and 
>cannot be removed.
>Another solution would be Jecel's ideas about permissions.
>
>> Similarly for all the other objects whose
>> existence is implied by the language (nil, true, the assignment
>> object, prototypical activations, etc.), their parents, and their
>> mirrors.  The object ID array is there because otherwise you wouldn't
>> be able to refer to the results of expressions entered at the VM
>> prompt.
>
>I have noticed that between sessions the IDs assigned to an object 
>are not fixed and
>unique, for example, when I open Self with the empty world and type 
>self at the prompt,
>the lobby is assigned ID <0>. However, if I type some expression 
>that evaluates to an
>error, the <0> ID is assigned to the process object and lobby gets ID <1>.
>
>>
>>
>> Anything not reachable from the set of roots (as enumerated in my
>> earlier email) _will_ be GCed.
>>
>> Mario
>>
>> ------------------------------------------------------------------------
>> Listen to Britany spears and more top artisits
>> now at audiohighway.com!
>> http://clickhere.egroups.com/click/395
>>
>> eGroups.com home: http://www.egroups.com/group/self-interest
>> http://www.egroups.com - Simplifying group communications
>
>
>------------------------------------------------------------------------
>Listen to Britany spears and more top artisits
>now at audiohighway.com!
>http://clickhere.egroups.com/click/395
>
>
>eGroups.com home: http://www.egroups.com/group/self-interest
>http://www.egroups.com - Simplifying group communications

 

     David Ungar
     Sun Microsystems Laboratories
     (650) 336-2618

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/self-interest
http://www.egroups.com - Simplifying group communications






More information about the Self-interest mailing list