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)
Previous text:
2003-05-14 00:29: 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.
Well, there's one a bit similar case where it would be useful: In the current implementation of nested functions, if a function accesses one variable in a surrounding one then the complete frame of the surrounding function remains. That means that many references to temporary stuff remains after the function returns, which leads to garbage that isn't obvious. If function frames were objects then a partial-free scheme would be a solution to this. It would however have to be done directly when the function returns; doing it in the gc would still be awkward.
/ Martin Stjernholm, Roxen IS