[Mono-dev] sgen optimizing
We have an application with a fairly common usage pattern. We send many messages in memory between a series of components (often with queues in the middle). In looking through sgen and defaults etc it would seem that by default there is a 4kb nursery. In this case we would have many of these small short lived messages getting promoted to the main heap. Is this a usage scenario where we might want to increase the size of the nursery to prevent the false promotions (aside from the messages we allocate very little else). Cheers, Greg -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sgen optimizing
sorry for type meant 4mb not 4kb (that would be a really small nursery!) On Mon, Oct 28, 2013 at 3:38 PM, Greg Young gregoryyou...@gmail.com wrote: We have an application with a fairly common usage pattern. We send many messages in memory between a series of components (often with queues in the middle). In looking through sgen and defaults etc it would seem that by default there is a 4kb nursery. In this case we would have many of these small short lived messages getting promoted to the main heap. Is this a usage scenario where we might want to increase the size of the nursery to prevent the false promotions (aside from the messages we allocate very little else). Cheers, Greg -- Le doute n'est pas une condition agréable, mais la certitude est absurde. -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sgen optimizing
Increasing the nursery size will reduce the amount of ephemeral garbage that gets promoted to the old generation. The downside of a larger nursery is the increased pause times for minor collections. Sgen has a separate nursery designed to reduce temporal garbage by making objects age in the nursery before promoting them. You can try it with MON_GC_PARAMS=minor=split. On Mon, Oct 28, 2013 at 9:40 AM, Greg Young gregoryyou...@gmail.com wrote: sorry for type meant 4mb not 4kb (that would be a really small nursery!) On Mon, Oct 28, 2013 at 3:38 PM, Greg Young gregoryyou...@gmail.comwrote: We have an application with a fairly common usage pattern. We send many messages in memory between a series of components (often with queues in the middle). In looking through sgen and defaults etc it would seem that by default there is a 4kb nursery. In this case we would have many of these small short lived messages getting promoted to the main heap. Is this a usage scenario where we might want to increase the size of the nursery to prevent the false promotions (aside from the messages we allocate very little else). Cheers, Greg -- Le doute n'est pas une condition agréable, mais la certitude est absurde. -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sgen optimizing
On 28/10/13 15:42, Rodrigo Kumpera wrote: The downside of a larger nursery is the increased pause times for minor collections. The concurrent-garbage-collector announced at the Mono 3.0 release would also be an alternative to avoid the pause times, right? If yes, is the concurrent-garbage-collector the default for multi-core archs? If not, why not? Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sgen optimizing
On Mon, Oct 28, 2013 at 10:48 AM, Andrés G. Aragoneses kno...@gmail.comwrote: On 28/10/13 15:42, Rodrigo Kumpera wrote: The downside of a larger nursery is the increased pause times for minor collections. The concurrent-garbage-collector announced at the Mono 3.0 release would also be an alternative to avoid the pause times, right? The concurrent collector is only for major collections, it doesn't help pause times for minor collections. If yes, is the concurrent-garbage-collector the default for multi-core archs? If not, why not? The concurrent collection remains experimental and under development. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
