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]> 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] > 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 -- 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
