TDPL: Manual invocation of destructor

[Jonathan M Davis]

On Monday, August 09, 2010 17:07:28 Andrej Mitrovic wrote:
> I don't have a lot of experience in this field, but my guess is people want
> to help out the GC be more efficient in some regard.
> 
> "Hey, GC! I know you take the trash out every day, but I just want to let
> you know that I've cleaned up my room and there's a whole bag o' dirt in
> here ready to be thrown out that you should know about. See ya later!"
> 
> My assumption is that the programmer probably knows when and how he uses
> memory more so than the GC itself. So my thinking is some kind of hybrid
> approach would be a good choice between safety and performance here. But
> correct me if I'm wrong, I'm walking in the dark really..

A GC is tuned with the idea that it will run periodically and free memory which 
is freeable at that point rather than frequently freeing it at the programmer's 
request like happens with manually managed memory. And since freeing memory can 
be expensive, it can be argued that it's actually more efficient to just let the 
memory not be freed until the garbage collector does its thing whenever that is. 
I've heard that there have been papers showing that that's more efficient, but I 
haven't read them. The issue is if the time that the garbage collector decides 
to run is when you're trying to do something time or resource-sensitive, and the 
garbage collector picks a bad time to run. But that's generally a fact of life 
with garbage collectors, and if it's an efficient garbage collector, then 
hopefully the hit is minimal.

Also, it's not like the garbage collector is likely to be really freeing your 
memory anyway, unless it decides that it just has way too much allocated. So, 
telling it that you want it to free something really is only getting the 
destructor called for you, which likely only matters if you have another 
resource of some kind (like file handles or something) which you need freed. And 
if that's what you need, you could just as easily call a function on the class 
to free that up as go and completely destroy it. The one thing that I can think 
of that clear() might get for you otherwise is helping the GC know that it any 
other references that that class holds aren't needed anymore, but if you no 
longer have any references to the object in question, the GC should already have 
that information.

Really, in the general case, it's going to be most efficient to let the GC do what 
it does. If it's well-written, it should do it efficiently. Trying to tell it that 
you know best is not likely to work well (in the general case, at least). If you 
really want to be freeing things as soon as you're done with them, you need to 
do manually memory management. Besides' s soon as you're keeping track of when 
it would be okay to clear() an object, that's pretty much what you're doing 
anyway.

- Jonathan M Davis