Here's a pattern, using Canvas as an example:
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-connections/
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 <[email protected]> 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
> [email protected]
> http://groups.google.com/group/v8-users
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
