You left out the best part of my last post. I'll try again, but this time with a more concrete example.
I implemented Canvas server-side. It consists of about 7000 lines of C++ code wrapping libcairo (the libcairo code is directly callable from JS as well) plus implementation of Canvas, CanvasDrawingContext2d, CanvasPathMethods, and Image in JavaScript. There are a number of methods and methodologies involved in using Canvas that create all kinds of Cairo native objects, as well as the Images which are also native. I don't see any way around the way the API works. Sure, I implemented (as Stephan Beal suggests) destroy() methods for all those things, but that's not part of the Canvas spec. So what's the point? You can run code written for the client to generate images using Canvas on the server side. In production, SilkJS users (some fortune 100 companies, in fact) use the feature and their demand for it is why I wrote it. None of that client-side code they're running server-side calls a destroy() function on objects created; destroy() isn't in the spec. SilkJS' architecture, as an apache style pre-fork server makes it possible to set the # of requests served per child to some low number so the child PROCESSES exit and that is a way to do garbage collection of all these native objects, but in any other context (e.g. NodeJS, a long running Context), a Canvas implementation that runs client-side code verbatim is going to leak memory. If you're interested in the JS Canvas implementation, it's here: https://github.com/mschwartz/SilkJS/tree/master/modules/Canvas/lib And the Cairo C++ code is here: https://github.com/mschwartz/SilkJS/blob/master/src/cairo.cpp Canvas is just one of many APIs that suffer from this issue. Maybe server-side support isn't a priority for V8, which is understandable. The browser is hugely popular and the driver for the development of V8 in the first place. However, I've taken to shutting down all my Chrome instances at work on Friday on my Ubuntu workstation, or else i show up on Monday to find Chrome has chewed through my 16G of RAM and most of my swap space. Maybe it is a browser issue as well. On Wednesday, July 11, 2012 1:41:01 AM UTC-7, Andreas Rossberg wrote: > > On 10 July 2012 16:26, mschwartz <[email protected]> wrote: > >> I think we're in 100% agreement that finalization time is a poor time to >> manage resource deallocation. This is the point of my suggestion that >> there be some mechanism to register a destructor with the JS engine for the >> object that is called when completely dereferenced. >> > > Well, again, how is the runtime supposed to find out, except by GC? That's > how MakeWeak works, too. It is finalization. You can't do better, unless > you buy into reference counting (with all its problems and overhead). > > > >> The ECMAScript 1.8.5 method I referenced is an example of how the >> language (or environment) has evolved to address things lacking in previous >> versions (such as the ability to protect properties from deletion). >> > > OK, but I would argue that API design and evolution would be the trivial > part of your proposal. > > /Andreas > > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
