Sorry for top posting (tablet gmail makes it difficult to do otherwise)... I should have specied that correct, well-defined behaviour is far, far more important to me than gc-related lags. For me it has never been a question of performance, but of well-defined (non- performance- related) behaviours and returning resources to their owners. Yes, i use finalizers for all of my bound native types, but that is so that they have well-defined behaviour and has 0 to do with speed. Obviously that requirement is out of scope for chromium, which is fine in and of itself but very negatively impacts v8's re-use in other projects because we embedders often have to expend undue amounts of energy shoe-horning finalization into not only our c++ code but also into our docs and users. (Yes, it's our own fault, but without bindings to interesting natives js is not much use.) On Jul 12, 2012 8:43 AM, "Sven Panne" <[email protected]> wrote:
> 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 -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
