Finalizing GC

[Jonathan M Davis]

On Sunday, March 31, 2013 20:51:52 H. S. Teoh wrote:
> On Sun, Mar 31, 2013 at 06:29:21PM -0700, Jonathan M Davis wrote:
> [...]
> 
> > It's my understanding that structs don't get finalized, because the
> > type information isn't there at runtime to do it. I don't know if that
> > can be gotten around or not, but my guess is that it's a permanent
> > restriction unless we start putting invisible member variables in
> > structs which have that information. I don't know though. Classes, on
> > the other hand, hold information on their actual types at runtime, so
> > the information is there to finalize them.
> > 
> > But regardless, there is _no_ guarantee that _anything_ on the GC heap
> > will ever be finalized, so any program which relies on anything on the
> > GC heap being finalized is buggy by definition, and I don't expect
> > that to ever change.
> 
> [...]
> 
> So what's the point of having class dtors then?!

Primarily so that non-GC resources might get cleaned up if you forget to do it 
manually. And it works with destroy, so if you're sure that you're done with 
the object, you can just call destroy on it instead of calling a clean-up 
function and then destroying it. But finalizers are really just a backup 
mechanism if you screw up.

I'm not sure that I would have chosen to make it so that finalizers have no 
guarantee that they're going to be run, but that's what was decided. But also, 
in order for finalizers to be guaranteed to be run, it has to be guaranteed 
that the GC will collect everything before the program ends, and for whatever 
reason (efficiency?) it was decided that that wasn't going to be done. I believe 
that it's guaranteed that finalizers will run when an object is collected, but 
there's no guarantee that it'll ever be collected. However, I don't know what 
all went into those decisions, so I can't really comment on why that's what 
was decide.

- Jonathan M Davis