--- Allen Wirfs-Brock Allen_Wirfs-Brock@Instantiations.com wrote:
The best explanation I've ever heard for why you are unlikely to see garbage collection generalized in this manner was by George Bosworth of Smalltalk/V fame. George's explanation basically goes like this: Garbage collection is a resource management solution for a resource that fits a particular "economic" model (very large resource pool, each resource has a very low value (who cares if you loose a few bytes out of megabytes), very high churn rate, moderate wastage is acceptable, etc.). Garbage collection algorithms and policies are all designed and specifically optimized for this specific resource management problem and simply are not appropriate for the management of resources subject to a very difference set of economics. In addition, there is no reason to believe that there is a single universal resource management mechanism that can be used to optimally manage all types of resources.
The problem with finalization is that it applies memory resource management policies to other resources (like postgres connections) that have a very different set of economics associated with them.
Allen_Wirfs-Brock@Instantiations.com
Well, that kind of argument encourages me to make my "other resources" really large in terms of memory consumption so that they cost roughly an appropriate amount when expressed in memory economics. I think a Postgres connection should be...umm...18Mbytes.
It seems to me that it would be a workable comprimise to use finalization for those objects which get/got handed around and are hard to track, but then something like an ensure: block to clean up the ones where that is easy to do. It seems to me that it would give you good performance in the common case, but then CYA (without requiring reference counting) in the complicated one. Does this just not work out well in practice?
-andrew
__________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/