Re: Storage management, was Compiler writers will love this language

> This works so that the objects are numbered consecutively as they are
> created. A cycle can then be detected if it points to another object with
> (depending on the setup) higher/lower number, which can be used to adjust
> the ref count so that deletion takes place appropriately also in cycles
> (which initially must have some external ref pointing at them). A problem
> arises though if, after an initial setup of references have been achieved,
> they are relocated dynamically, creating new cycles. That is hard to track
> down. But if that does not happen, one can make a version building on this
> SCC algorithm to remove the cycles as well (or so I remember).


This is interesting.


Leaving aside the SCC stuff, if I may (I haven't given this a great
deal of thought, but it seems that this is effectively adding
mark-n-sweep GC to supplement the ref-count system, which I gather
from this thread is a well known technique), what I interpret this as
(and correct me if I'm wrong) is:


If P acquires a reference to a newer object Q, then Q's ref-count is
incremented. If P acquires a reference to an older object Q, then Q's
ref-count is NOT incremented.


This makes the objects-and-references graph acyclic, overcoming the
cyclic-reference problem.


I suspect that there MUST be problems with this, although I don't see
them, because it doesn't "feel" like a new idea, and if it worked,
then no-one would be talking about the cyclic-reference problem.


So: Question: What are the problems?

Return to the comp.compilers page.
Search the comp.compilers archives again.