Re: Re: Re: Re: my garbage collector sucks

Mark Hahn wrote:

> There is a ton of garbage collection reference material out there that isn't
> aware of this.

http://www.sellsbrothers.com/spout/default.aspx?content=archive.htm#refCountRotor

"The goal of adding ref-counting to Rotor is to measure the performance 
effects of a deterministic finalization-like model that we gave up when 
moving from COM/C++/VB6 to .NET. I say "DF-like" because we're not 
getting DF, because the price of determinism is that sometimes an object 
is never finalized, e.g. cycles. We can do better."

 >...
> Anyway, I have to weigh all the advantages and disadvantages in making the
> Prothon decision.  Having a generational garbage collector that burns a lot
> fewer cpu cycles, works better with multiple cpus, and is easier to code in
> C outweighs this finalizer issue.  Adding file close statements not only
> protects against different garbage collectors but is explicit and good
> coding style for readability.

Explicitly closing files raises the exact same problems as explicitly 
deleting memory. The only difference is that the average program deals 
with fewer files than memory objects so the issue tends to be more 
managable. But there is nothing magical about memory that says that it 
is virtuous to let the implementation deal with it while it is naughty 
to depend upon the implementation close files.

I'm not pushing for reference counts: I'm just tired of illogical 
arguments (not just here) against deterministic finalization.

By the way, you can get a subset of the benefits of deterministic 
finalization if you implement a feature that scopes objects to their 
containing functions as stack variables in C/C++ are scoped to their 
containing functions.

http://c2.com/cgi/wiki?DeterministicFinalization

As long as you are careful to never pass these objects out of your 
function you are okay...

  Paul Prescod