Thanks for the detailed explanation Vyacheslav! I've updated the post accordingly.
On Saturday, November 3, 2012 2:11:41 PM UTC-7, Vyacheslav Egorov wrote: > > 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 <[email protected] <javascript:>> > 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 <[email protected]> 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 [email protected]<javascript:> > > To unsubscribe from this group, send email to > > [email protected] <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
