Node 0.12 seems less aggressive with GC than node 0.10

[Sanath Kumar Ramesh]

Hello,

Few hours after switching to Node 0.12, RSS in my node process in production started quickly climbing to 1GB. With Node 0.10, my node process's RSS hovers around 300MB and rarely goes up to 500MB. When I switched back to Node 0.10, memory was back under control.  

I reproduced the problem locally by making a bunch of parallel requests to my server. RSS on Node 0.10 maxed out at around 700MB, and dropped to ~500MB after the requests stopped. But with Node 0.12, memory stayed at around 1.2GB for many minutes after requests stopped. I called global.gc() couple of minutes after stopping requests. 0.12 dropped to 600MB and 0.10 dropped to around 300MB. When I called global.gc() a few more times, RSS on 0.12 will eventually drop to around 300MB.

Is the garbage collector on Node 0.12 less aggressive? Is this an intended side-effect of switching to 0.12? I couldn't find any information regarding this in the release notes too.

Thanks,

Sanath

PS: I looked at heap dumps before and after local repro requests. I didn't find anything alarmingly growing or wrong.

[Mark Blackman]

I've certainly seen surprising amounts of RSS used for trivial apps like the "hello world" example under node 0.12  That starts with about 20M of RSS, hit it hard with a simple benchmarking client like 'ab' and it shoots up to 70M of RSS. What on earth could it possibly need 50M for just to return the string 'hello world' over HTTP?

I realise node.js is constrained by the behaviour of V8, but still, can't V8 do any better? I don't know what your app does but an RSS of 300MB sounds pretty scary to me.

[Jérémy Lal]

Projects like https://github.com/flyover/v8like are very interesting
because JavascriptCore

* can replace v8 in node - it's striking how easily even though i
suppose hell will be in the details

* runs on a wider range of platforms, just like webkitgtk does, see
https://buildd.debian.org/status/package.php?p=webkit2gtk

* is a very different implementation - i personally find it more
beautiful because it uses existing libraries like LLVM

* deals with memory way better than v8 when doing intensive, ram-eating
server tasks - a webkit-based browser was the only one capable of
dealing with a 8GB memory load without hanging in a specific job i did
last year - where chrome or firefox failed miserably.

However, it is also less embeddable and more osx/linux oriented.

Cheers