[gclist] Are the traces sequential?
Giuliano Carlini
giuliano@ix.netcom.com
Mon, 17 Jun 1996 11:43:59 -0700
Rick,
It sounds as if you think I've actually implemented this. I haven't. I described
it to get feedback before starting work on this as a project. I don't believe
Matt has implemented it either yet. It sounds like he might soon though.
I'm curious if you see any problems with my implementation of Matt's algorithm.
g
>Point 1.
>
>Is it true that after an initial trace is done and a suspected garbage train
>is discovered then a second confirming trace is done to insure that nothing
>has changed since the first trace.
I described it as a second pass. I'm not sure that is necessary. Perhaps it can
be done as the back-search is returning. In any case I believe that some type of
barrier is needed, and some check that no barrier has been hit is needed.
I'm not sure if Matt agree's or disagree's about the need for a barrier. His
algorithm may have eliminated the need for it.
>Just to clarify this point when I say
>nothing has changed I mean that no pointers have been passed out (read barrier
>protection)and no pointers to an object have arrived (write barrier
>protection) since the first trace.
Yes. In fact Gustavo noted that what I described initially is not enough. You
must set a barrier against any use or mention of a scion in an RPC.
>Point 2.
>
>The length of the trace is not bounded.
Not sure exactly what you mean here. I believe that the trace is bounded by the
length of the cycle. And the cycle is bounded by the memory on the network.
g