Hi All, We're seeing a GC behavior change when we upgrade from mono 2.6.4 to 2.10.6 and we're curious if others are seeing a similar difference and if it is something we should be concerned about.
In short: our process address maps have jumped from consistently less than 2000 to more than 100,000 during typical operation when we upgrade from mono 2.6.4 to mono 2.10.6; same app running against each mono version has surprisingly different address space allocation patterns. Our linux application is memory intensive, and can use more than 10 gigs of ram, so having so many blocks being allocated and frees isn't that surprising. But the behavior change with 2.10.6 gives us pause (actually we saw it first with 2.10.3). We first noticed this difference by hitting "mmap(...PROT_NONE...)" asserts and crashes in the boehm collector because we were hitting the linux kernel's default 65535 limit on address maps per process. Bumping that using sysctl allowed us to continue, and we're fine bumping it because we have plenty of ram. There was one related change to libgc in mono 2.10 replacing an unmap to be a mmap(PROT_NONE) for unmapping gap regions. That appears to be a fix for Darwin. But when we revert that one change (since we're on linux) we still see these almost two order of magnitude more maps. Just takes a little longer to hit it. Anyone else see this behavior? Or are there some tunable parameters that we might want to play with? Note: we tried sgen briefly and encountered crashes. We couldn't find separable test cases for those crashes to file bugs; we just have stayed with the parallel mark Boehm collector for now. Thanks much, David
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
