Garbage Collection Idea

[Craig Black]

> If what you propose could be done with no overheads, then yes it would
> be faster.  The question is: what are those overheads?  Specifically,
> how much larger will code be in order to maintain this pointer stack,
> and how efficiently can it manage this stack?  The current
> implementation has a head-start in that it requires no management code
> (or at least, none that I'm aware of).

Yes, there will be a trade off there.  However, I don't expect huge delays 
from adding a couple push and pop instructions here and there.  GC, on the 
other hand, could really use the speedup.  I think overall this would be a 
very favorable trade-off.

> Another potential problem is this:
>
> # class Foo { ... }
> # Foo bar = new Foo;
> # void* quxx = cast(void*)bar;
>
> What happens now?  We can no longer tell what type of memory is pointed
> to by quxx, but we *still* need to scan it.  The only way I can think of
> to solve this would be to mark each segment of memory with the kind of
> allocation (class, struct or otherwise), and what the type is.  That, or
> you can just revert to blind scanning, but then it's no better than the
> default GC (and more complex code-wise).

I didn't initially consider this case, but it wouldn't be to hard to 
accomodate it.  Each allocation unit, whether it is a class instance or not, 
would have to get an id that describes its identity.

> I'm not saying it's a bad idea; I assume the current implementation
> exists as it does because it's a hell of a lot simpler to code, and it's
> much easier to integrate.  I think the best thing to do would be to
> actually code it; take a reasonably sized program, and convert it to use
> a "smart" collector, and see what the difference is.

Yes.  Performance should be benchmarked for as many applications as 
possible.

> I wonder if .NET and Java use "smart" collectors.  I know that .NET uses
> write barriers, which would suggest that it does.

Don't know.

> I suppose that if nothing else, the advantage of this system would be
> that it wouldn't mistake other fields for pointers, thus potentially
> keeping objects alive when they're not longer actually referenced.

I think it would increase performance also.