Memory management flags in V8
A lot of people are linking to a blog post about V8 memory management, so I thought I would write my own notes on the flags too.
--max_new_space_size (in kBytes)
The new space is where objects are normally created. With any luck they die young and GC in this space is very fast for dead objects, so it's a nice optimization. The new space normally sizes itself automatically, and you can't increase the max size without recompiling V8, so there is not much need to tune this one. If you want to keep pauses short you can pass a value of 1024 or less to this flag, and the pauses associated with new-space GCs may be reduced from up to 30ms to more like 0-2ms. Throughput may suffer.
--max_old_space_size (in Mbytes)
This defaults to 700Mbytes on 32 bit and 1400Mbytes on 64 bit. If you want to allow V8 to grow more than this then you can set it higher. The maximum is not known. If you set this very high, then V8 will save some time (it's a space-speed tradeoff) by using more memory. File a bug if you have a use case where
a) memory use rises in an unbounded way with a high value for this flag
b) the program runs without out-of-memory when you set the limit lower
--max_executable_size (in Mbytes)
We normally limit this for security reasons. It's a defence-in-depth defence against heap spraying attacks. On the client, don't increase it unless you have truly gargantuan programs. On the server side, heap spraying attacks are not normally feasible so this is not so important.
--gc_global, --gc-interval, --incremental_marking_steps
These are debugging flags for the developers of V8. You basically never want to use them.
Lots of interesting debugging info will be produced by this.
--incremental_marking (default: true)
Switch this off to get slightly higher peak performance and much longer pauses.
This may reduce memory use a bit, but it will cause long pauses. If this makes a big difference to the memory use, please file a bug so that the compaction heuristics can be improved.
This will dramatically reduce max pauses (esp. with a small max new space size), but may cause memory use to rise. Whether you see any effect on memory use depends on your workload. Most JS engines do not have a moving compactor, so using this flag can make memory use look more like it would on another engine.
--compact_code_space (default: true)
As with --never-compact, switching this off may be beneficial for pauses, and may hurt peak memory use.
I would agree with the osnap blog
here. You probably want this flag, and you may not want it any more with future node releases.
This lets you second guess the GC heuristics by starting a GC with the global gc() function. You are almost certain to lower performance and cause more pauses with this option.