[Mono-dev] tuning sgen performance & bug

[Rodrigo Kumpera]

There are two situations that make sgen slower than boehm.

The first is a non-generational workload. If your survivor rate is too
high, a generational collector
can't compete with single space one like boehm.

The second one is if you have too much of the old generation pointing to
young objects causing minor collections
to scan way too much memory to be profitable.

The nursery size should usually be a not so small fraction of the total
heap you expect. As a good guess you can use
1/10 - 1/20.

Are you expecting to have a heap of multiple Gigs? Because a 2Gb nursery
will need at least 8Gb of major memory.

About your crash. I just noticed a very silly thing, we have never ever
tried sgen with huge nurseries because there's a
128Mb implicit limit due to some internal sizes.

Jonathan, for such huge heaps, sgen will need the parallel collector to
compete with boehm on linux, which is a not
very mature piece of code both in stability and performance.


On Fri, Aug 31, 2012 at 2:03 PM, Jonathan Shore <jonathan.shore at gmail.com>wrote:

> HI,
>
> sgen is now working for me (thanks to a subtle bug fix for
> thread-local-storage by Zoltan).   However, for one application, *sgen is
> 25% slower* than the same with the boehm collector.   I am processing
> some GBs of timeseries data, though only evaluating a window at a time.
> As the window reaches some size, older objects in the timeseries are
> dereferenced.   The object size is 88bytes, but generate many millions
> across the course of a run.
>
> I suspect that the nursery is too small, so that the objects I want to
> collect are now in the main heap.    Towards that end I wanted to extend
> the nursery, and attempted this:
>
> export MONO_GC_PARAMS="nursery-size=2g"
>
> This causes mono to crash immediately, with:
>
> * Assertion at sgen-gc.c:1206, condition `idx < section->num_scan_start'
> not met
> ...
>
> (this is on linux with the latest code on master, roughly 2.11.3+)
>
> I took a look at the code, but requires too much context for me to
> understand the real cause of the issue.   I am guessing that there is some
> assumption re: the size of the nursery, block size, etc.
>
> Finally, I am interested in trying the "copying collector" as discussed in
> this blog entry:
>
> http://schani.wordpress.com/2011/01/10/sgen-the-major-collectors/
>
> I'm wondering if will get some performance advantages with this approach,
> whereas the nursery may be too small for my garbage working set.
>
> Ideas?
>
> Thanks
> Jonathan
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120831/58da2ced/attachment.html>