Thanks for the lengthy reply. I need to start studying GC's before I assume more things like that. :)
On Tue, Aug 10, 2010 at 3:11 AM, Jonathan M Davis <[email protected]>wrote: > 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 >
