> function foo() {
>   var c = new Canvas();
>   var ctx = c.getContext('2d');
>   var grad = ctx.createLinearGradient(0,0, 10,10);
>   // do something / render
> }

> There's now a native cairo_surface_t created (new Canvas).  The c variable
> has a this.surface referencing the native surface object.
> There's now a native cairo_context_t created (c.getContext). The ctx
> variable has a this.ctx referencing the native context object.
> There's now a native cairo_pattern_t created (c.createLinearGradient).  The
> grad variable has a this.pattern referencing the native pattern object.

> All three need to be cleaned up at some point.

> There are no "destroy" (destructor) methods defined in the W3C spec for
> Canvas, Context, Gradient, etc.  Nobody is going to call them (they don't
> client-side), unless writing non-portable SilkJS specific code.  And
> ideally, the code should be portable between client and server - that's one
> of the best features of JavaScript running on both sides.

> I'm fully aware of the issues with finalize and reference counting based GC,
> etc.   Stephan made his rant about garbage collection and destructor issues
> in that link I posted in my first message.  Things haven't changed.  He and
> I have been and still are developing complex API for server-side, and this
> is an issue we both face.  Surely every API designer faces the same problem.
> Assist from V8 in addressing the problem would benefit a wide audience.

> As for my choice to force GC:

> http://blog.caustik.com/2012/04/08/scaling-node-js-to-100k-concurrent...

> 2) V8′s idle garbage collection is disabled via “–nouse-idle-notification”

> This was critical, as the server pre-allocates over 2 million JS Objects for
> the network topology. If you don’t disable idle garbage collection, you’ll
> see a full second of delay every few seconds, which would be an intolerable
> bottleneck to scalability and responsiveness. The delay appears to be caused
> by the garbage collector traversing this list of objects, even though none
> of them are actually candidates for garbage collection.

> In my case, I know when it is a good time to force a GC.  It is being done
> in process that is about to block in accept().  If it ties up a CPU core for
> a bit, it is not going to stop the other processes from running, nor is the
> GC going to pause the server in action.

> (The above is one of numerous WWW pages I've read about scaling NodeJS,
> garbage collection pauses during benchmarks, etc.)

> On Jul 11, 2012, at 7:38 AM, Andreas Rossberg wrote:

> On 11 July 2012 15:35, Michael Schwartz <myk...@gmail.com> wrote:

>> GC finalization actually works for SilkJS.  In the HTTP server, there are
>> two nested loops.  The outer loop waits for connections, the inner loop
>> handles keep-alive requests.  At the end of the inner loop (e.g. when the
>> connection is about to be closed), I force a GC (or at least try to).

> Hm, I don't quite follow. If you actually have a specific point where you
> know that you want to dispose a resource, why is it impossible to dispose it
> directly at that point? Or if there are many of them, you could maintain a
> set/map of them.

> In any case, before you conclude that finalization is the answer to your
> problems, let me +1 Sven's recommendation on reading Boehm's paper on the
> subject. Finalization is pretty much an anti-pattern. There are some rare,
> low-level use cases, but usually it creates more problems than it solves.
> That's why we only provide it in the C++ API.

> Also, I should mention that forcing a GC manually is highly discouraged.
> That causes a full (major, non-incremental) collection, which generally is a
> very costly operation that can cause significant pause time, and basically
> defeats most of the goodness built into a modern GC.

> /Andreas

> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users

> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users