Memory management and tuning - nodejs

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Memory management and tuning
Received-SPF: pass (google.com: domain of vego...@google.com designates 209.85.216.51 as permitted sender) client-ip=209.85.216.51;
MIME-Version: 1.0
Sender: vego...@google.com
In-Reply-To: <03d68c56-5f80-41ea-9786-c099c5ae4818@googlegroups.com>
References: <d51eb9ca-e29c-4854-8c38-8e7fcdb8a76d@googlegroups.com>
	<CAHQurc_18Myp5epG-h8U1MWz+yxwbCD0Arb9p4zWMj1J5Bg...@mail.gmail.com>
	<03d68c56-5f80-41ea-9786-c099c5ae4818@googlegroups.com>
Date: Sat, 3 Nov 2012 22:11:10 +0100
Message-ID: <CAPD5VRvgkDE5GLj3jb7CizcPmfdGJ7hCA9N7mTaSd=C5s5y...@mail.gmail.com>
Subject: Re: [nodejs] Memory management and tuning
From: Vyacheslav Egorov <vego...@chromium.org>
To: nodejs@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1

A lot of those flags exist solely for debugging purpose: it's
sometimes useful to switch something off and see if some issue stays
to be reproducible. This allows to quickly bisect things in a system
which has a lot of moving parts. Debugging flags are really not
intended for any other purposes and should not be used unless you have
an intimate understanding of V8.

Some flags outlived their usefulness (like --incremental_marking_steps
that was quite useful during initial development of incremental GC to
understand if there is an invariant violation between steps or the
problem is somewhere else entirely) and should be probably killed to
avoid confusion.

--collect_maps flag has a somewhat confusing name as well. Its name
implies that maps are not collected when it is turned off, however
this is not true. Maps just start to die in a different way. When
collect_maps is on then edges in map transition trees are reversed
during garbage collection and trees start dying from their leaves:
paths that do not lead to any live objects are cleared from the tree,
but roots are retained. When collect_maps is off transition trees are
just dying from their roots like a normal trees... It's likely that
less maps will die this way due to connection between initial map and
the constructor, but fully dead trees will be surely reclaimed. In
some cases application can exhibit pathological patterns of hidden
classes construction that cause performance degradation due to
frequent GCs when --collect_maps is enabled because parts in
transition tree reappear again and again after being pruned as dead.
But I would not recommend to touch this flag unless you deeply
understand how V8's hidden classes work.

Code flushing (--flush-code) tries to discard compiled code do reduce
memory consumption. Code will be recompiled if somebody needs to
execute this function again. At the moment only non-optimized code is
flushed but in the future V8 might start flushing generated optimized
code as well as it is known to cause increased memory pressure in some
pathological cases. Caches flushing (--cleanup_code_caches_at_gc)
clears inline caches and other suplemental caches used by V8 to
collect typefeedback and adapt for the application. Flushing them
reduces memory pressure (caches use small complied code stubs that can
reference other objects e.g. hidden classes that are no longer
"relevant") and ensures that feedback is not stale. Again both flags
should not be used unless you understand V8 code generation pipeline
from alpha to omega.

--
Vyacheslav Egorov


On Sat, Nov 3, 2012 at 4:16 PM, Joel Rolfe <jro...@gmail.com> wrote:
> Thanks for the feedback Ben, I updated the use notifications section with a
> pointer to the open issue.
>
> Re: GC switches that didn't get much love in the article - if I didn't
> understand why you'd want to toggle it, then I didn't say anything about it.
> For example, why turn off the collect_maps option?  Or
> incremental_marking_steps (I'm probably not understanding that term -
> wouldn't incremental marking without steps be non-incremental marking?).  So
> basically, if there were any situations that you'd encountered where it had
> been useful to turn one of these off, then that's definitely something I'd
> want to capture.  Otherwise, I figured I'd just list them for completion's
> sake.  Other ones were:
>
> --lazy_sweeping
>
> --flush_code
> --cleanup_code_caches_at_gc
>
>
> On Friday, November 2, 2012 8:55:15 PM UTC-4, Ben Noordhuis wrote:
>>
>> On Fri, Nov 2, 2012 at 6:13 PM, Joel Rolfe <jro...@gmail.com> wrote:
>> > Hi All,
>> >
>> > Relatively new to node (about a month under the belt), from a
>> > java/relational stack background.  I spent today trying to understand
>> > memory
>> > management and configuration, as I found it difficult to find a single
>> > source of documentation on the various options and implications.
>> >
>> > I've collected my research here, and would love some feedback, or any
>> > additional detail where possible.
>> >
>> > http://code.osnap.us/wp/?p=21
>> >
>> > Thanks!
>>
>> Nice article, good job.
>>
>> > There had been discussion of rewriting the algorithm, but I have not
>> > been
>> > able to find any updated status.
>>
>> The tracking issue is here: https://github.com/joyent/node/issues/3870
>>
>> Admittedly, not much actual code has been written.  The main issue is
>> that we can't introduce regressions for existing workloads.
>>
>> Re: GC switches, let me know which ones you're not clear on.  I can
>> probably fill you in.
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
