[Gc] Determining if an object is valid
haberg-1 at telia.com
Thu Aug 30 06:52:33 PDT 2012
On 30 Aug 2012, at 12:18, Henning Makholm wrote:
> On 2012-08-29 15:35, Hans Aberg wrote:
>> Is there an inexpensive way to determine if an object is still valid? Using
>> GC_is_heap_ptr(), a C++ object on the function stack can be marked so that
>> it moves to the heap when its scope expires. But if all references to it
>> are dead, this is unnecessary. There seems no simple way to determine this,
> 1. The only way to figure out with certainty if an object is still live is to
> do a full marking phase, which is rather expensive.
I suspected this, just want to make sure.
In my situation, though, the object isn't on the heap, but is known to be boxed at one point in time. This boxed reference can then be passed around, breaking local scope. For example, let O (for object) be the class used to box elements of class A, and take:
O a, b;
a = new A();
b = A();
O c = A();
Then when this inner scope terminates, 'a' is already on the heap, b should be moved, and the object pointed to by c need not be moved. Right now, I use GC_is_heap_ptr() to make sure both b and c are moved. So A object c references will first be moved, and collected at some later time by the GC.
> If you have local scopes
> with such objects opening and closing often, an average one wouldn't even
> live long enough for a GC to take place, in which case EVERY heap object
> ever used during its lifetime would still count as live.
The problem is caused by admitting passing a boxed reference outside the scope.
One way to avoid might be to use ordinary C++ unboxed references A&, so that one uses boxed references O when really needed, but the problem is the language not really made to handle that well.
> 2. You'd need to use some kind of special mechanism to track the objects that
> point to your stack object such that you can rewrite them when you move the
> stack object -- without this tracking mechanism itself keeping the referring
> objects alive at a GC.
When an object on the stack is boxed, it gets a handle on the heap, so moving later is not a problem. The problem is avoid having them moved when not needed.
> The GC does support various finalizer tricks that can
> be used for this, but since they need heap allocation, they would almost
> surely be just as expensive as just heap-allocating your "stack" object from
> the beginning.
I suspect that, too.
More information about the Gc