Here's your Node.js performance tip of the week - how garbage collection works and how to monitor it

[Shubhra Kar]

Coming into Node from a Java background GC always intrigued me. The JVM and CLR have this mastered as a science.

Here is what I discovered for Node and V8. Should be helpful to newbies

http://strongloop.com/strongblog/node-js-performance-garbage-collection/

Kind Regards,

Shubhra Kar

Product Manager - StrongLoop

Rapidly develop APIs in Node.js, plus get DevOps capabilities like monitoring, debugging and clustering.

[zladuric]

Hi Shubhra,

Very nice, detailed article. It explains the standard GC methods that the V8 uses. I've also skimmed

What I'd like to add is a little bit of wisdom I've picked up at the MLOC-JS.com conference in Budapest this February. Ben Titzer from Google Chrome division was explaining a little bit of this, how does GC work in V8, and he's shared a great tip:

    create as many objects as you can and just discard them.

They're putting a lot of effort into new-gen optimization - it is a lot smaller but a lot faster. When your objects get promoted to tenured generation space, then it's a lot more work for V8 to manage them + the space size itself is bigger, all of which adds a bit overhead.

So what he has said is not to be afraid to just create as many objects as you need and just keep discarding that. 

I guess that translates to "create as many small local scoped vars as you need, and V8 will take care of it all".

Or perhaps I've misunderstood it all. 

[Norman Paniagua]

Thanks for sharing.. I take a look at the post

[Ben Noordhuis]

On Thu, Jun 26, 2014 at 12:08 PM, zladuric <zlad...@gmail.com> wrote:
> What I'd like to add is a little bit of wisdom I've picked up at the
> MLOC-JS.com conference in Budapest this February. Ben Titzer from Google
> Chrome division was explaining a little bit of this, how does GC work in V8,
> and he's shared a great tip:
>
> create as many objects as you can and just discard them.
>
> They're putting a lot of effort into new-gen optimization - it is a lot
> smaller but a lot faster. When your objects get promoted to tenured
> generation space, then it's a lot more work for V8 to manage them + the
> space size itself is bigger, all of which adds a bit overhead.
>
> So what he has said is not to be afraid to just create as many objects as
> you need and just keep discarding that.
>
> I guess that translates to "create as many small local scoped vars as you
> need, and V8 will take care of it all".

That's not bad advice but there's a caveat.

The garbage collector in V8 is generational. It needs to know what
new space objects contain references to old space objects and in order
to get that information, stores to properties in new space objects go
through something called a write barrier[0].

What that means is that an assignment like `object.x = value` gets
translated into code that conceptually looks like this:

// Update write barrier unless value is an int.
if (IsSmallInteger(value) === false) {
RecordWrite(object, 'x');
}
Store(object, 'x', value);

(The write barrier is elided when the value is an integer because
integers are not stored as objects and don't reference other objects.
Numbers can be heap-allocated but signed integers that fit in ~30[1]
bits usually are not.)

You shouldn't let the above worry you too much but in performance
critical code, it sometimes pay not to mix new and tenured objects.
(Something node.js core doesn't do too well, alas. The http and
stream modules, for example, have lots of backlinks between objects
with different lifetimes.)

[0] Not to be confused with a hardware write barrier.
[1] The exact width depends on the hardware architecture.

[Zlatko Đurić]

Where can one look for this code, write barriers and stuff? (I guess curiosity is getting the better out of me, or however the saying goes.)

2014-06-27 13:15 GMT+02:00 Zlatko Đurić <zlad...@gmail.com>:

So that means that 'I guess that translates to "create as many small local scoped vars as you need, and V8 will take care of it all, as long as they don't point to global scopes and other stuff?

Or is this _always_ something that needs to be checked, regardless?

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/tx6FCaVvf44/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAHQurc_xmhTG2oQ%2B8%3D0rvNyfqeb5ksrxAhpviEudTAz-bJ3YUA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
Zlatko

--
Zlatko

[Ben Noordhuis]

On Fri, Jun 27, 2014 at 1:17 PM, Zlatko Đurić <zlad...@gmail.com> wrote:
> Where can one look for this code, write barriers and stuff? (I guess
> curiosity is getting the better out of me, or however the saying goes.)

I'm afraid it's scattered all over deps/v8/src. Grep around for
'WriteBarrier' and make sure you have a couple of hours. :-)

I'll be happy to answer any questions you may have but it's probably
best to direct them to the v8-users mailing list[0].

[0] http://groups.google.com/group/v8-users