A really accurate solution is to analyze the variable dependencies in destroy() and call it as soon as all those variables run out of references. Barring that I think it's clear that it should wait until the object is completely free of references since modifications through locatives might affect destroy(). Garbage collection semantics should always be secondary to such effects of "normal" execution.
Your idea with locative chains has the disadvantage that it complicates normal dereferencing. Overall I think it'd be simpler to contain the extra complexity in the gc. It could treat the pointed-to svalues as objects of their own and put markers on them directly.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-14 09:52: Subject: Pointers/lvalues
The object shouldn't be freed completely in any case, unless the locative is weak. The gc would have to do more bookkeeping to perform partial freeing as you suggest, and I can't see any big advantage with it.
I've seen code to do that. For a copying gc it's straight forward, perhaps it's harder for a mark&sweep like pike's. [*]
As long as there are no destroy method on the object, freeing everything but the svalues the locatives point to seems like the right thing to do (it collects memory which will never be referenced again). If also you have a destroy method, it's harder to say what's correct.
[*] One way to do it with mark&sweep may be as follows: First make sure that when a locative is dereferenced, chains of locatives are collapsed. I.e. a locative A pointing to a locative B pointing to a svalue S should behave in the same way as a locative directly to S (for this to work, locatives need to be write-once, I guess). Make the gc collaps locative chains: When it finds A, replace it with B. There need to be some protection to keep the thing from crashing if a locative chain is circular; but circularity detection in a straight linked list is easy.
So, when the gc finds an object with locatives pointing into it, but no other references, allocate a new svalue (perhaps there should be a separate allocation area for these isolated svalues). Copy the svalue from the object to a new location, and replace the old svalue with a locative pointing to the new location. Leave the object around for now.
The next gc will collapse locative chains that pass through the old object, so that it loses all the locative references, and can be deallocated completely.
/ Niels Möller (med röd bil)