Actually finalization in reference counting GCs is much more
predictable than in GCs that mark through the heap.
Contrary to want you might think --nouse-idle-notification does not
disable automatic GC in V8. What it does is tells V8 not to perform GC
actions (be it advance the sweeper, incremental marker or do a full
GC) in response to IdleNotifications that embedder (node.js in this
case) sends to V8.
If V8 sees fit (e.g. on allocation failure) it _will_ perform it and
you can't disable that.
[also running through all objects is kinda how GC works, though it
should be done in increments]
--
Vyacheslav Egorov
On Wed, Jul 11, 2012 at 5:02 PM, Michael Schwartz <myk...@gmail.com> wrote:
> 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 <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
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
