[gclist] Distributed Garbage Collection Revisited 1
H.C.C.Rodrigues
hccdr@ukc.ac.uk
Thu, 04 Jul 1996 12:08:40 +0100
Matthew,
I wrote:
>> I think it is not necessary an infinite number of new incoming references
>> appear before the distributed trace terminates to not terminate the algorithm.
>> We can have a cycle of objects spawning two processes being reachable from a
>> root either in one process or in the other. The DGC may never reach a root.
>>
>
>We are definitely not seeing eye-to-eye here. Could you develop a
>scenario with a sequence of messages which shows what you mean?
>
>> >1) A remotely rooted object. If there are no garbage processes, we
>> >can just use this as proof the object is alive.
>>
>>I think the problem I presented does not exist if you consider the objects
>> being remotely
>> accessed live. In this case I imagine that the back-search would terminate.
>> What would happen when a "grey" object is remoteley accessed?
>
>Think about this. When can a grey object be accessed, and what does
>its being accessed mean, at each point in time?
Sorry about this. Is very dificult to explain what I am thinking by eamil.
I am going to try to design an example:
___________________
/ |
| |
V |
R ScionA1 |
| | |
V V |
ObjA2<--ObjA1 |
| | |
| V |
\---->StubB1 |
| Space A |
| ---------- |
V Space B |
R ScionB1 |
| | |
V V |
ObjB2<--ObjB1 |
| |
V |
StubA1 |
| |
\-------------------
This is the example I was thinking. If you start a back-serach say at object
A1, the algorithm will colour grey ScionA1, StubA1, ObjB1, ScionB1, say at
time 1. T time 2, ObjA2 invokes ObjB1 that copies <ObjB1,StubA1> to ObjB2.
ObjB1 was acessed and it is grey.
Am I write?
However, the problem I presented in my first message, it is not a problem.
Gustavo, Giuliano barriers resolve the problem.
Helena Rodrigues.