The beating continues... ;-) Regarding Boehm's "finalization is rarely needed": I think statement generally holds, *except* for the case we are discussing, namely writing a binding for a library with explicit allocation/deallocation where the deallocation part is not exposed in the binding. While it is very convenient for the user of such a binding, it simply wipes some complexity of the original library under the carpet, hoping for a magic solution from the binding language/runtime.
When one uses finalizers for this magic solution, one faces another problem, namely the usual tradeoff between latency and throughput: For the vast majority of use cases of a GC, throughput is much, much more important than latency. In theory one could write a basically zero-latency GC (e.g. by doing reference counting on strongly connected components) where finalizers would fire immediately, but the overhead is so huge that no real collector I know of does it this way. So using finalizers in the real world will always involve some kind of delay, and you simply have to live with that. If the delay is intolerable and you have certain points in your application/library/framework where you know something about the lifetime of the underlying library objects (which seems to be the case for our example), you can deallocate the "dead" ones by hand, using the finalizer calls from the GC only as an additional hint to do this early. Having written several library bindings for myself, I am quite aware of the fact that the additional complexity of doing this in the binding layer is not nice, because it involves some housekeeping of the library objects there, but this is the price of hiding complexity from the user of the binding. Regarding Boehm's "Section 3.3, bullet point #1:": This assertion is true, because in a library binding there are at least *2* objects involved, in our example the JavaScript canvas object plus the underlying Cairo surface. Cheers, S. -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
