[Mono-list] Unable to create more than 1000 objects.

[Rodrigo Kumpera]

On Mon, Dec 12, 2011 at 11:11 PM, Dragony <cschmid at rapidshare.com> wrote:

> You did not understand my point(s).
>
> The FIRST point is, that with the Boehm GC, I can create objects really
> fast. Even 500 millions. BUT when the memory consumption is over 4 GB, it
> crashes under some conditions when you want to create a new object. So the
> point of my test program is to create many big objects just to demonstrate
> that Mono crashes after 500 objects IF your memory consumption is already
> over 4 GB when you reach that point.
>

Boehm is not well suite for large heaps, it hard some intrinsic limitations
on heap size.
Let me see if I understand you meant, sgen crashes if you try to allocate
another 2Gb
of memory after you reached 4Gb?

This is pretty odd, as sgen doesn't have any sort of limitations regarding
allocation of
large objects. Unfortunately I can't test it as my machine doesn't have
enough memory.



>
> The SECOND point is, that SGen GC has NOT this limitation, BUT it has a
> serious speed issue. When you create 500 million objects with each one 100
> bytes, you come up with 50 GB of memory consumption. This WORKS in SGen,
> but
> it goes slower and slower the more memory I already use. When I have
> reached
> 12 GB, it can be said its then unusable.
>
>
Garbage collection performance is proportional to the heap size, so if you
want to work
with such massive heap and that many objects, don't expect it to fly. You
can try the
parallel collector, as it should shine on such massive heaps.

Another option is to use arrays of valuetypes and use indexing instead of
direct references,
this is a much more GC robust design.

Overall, this doesn't surprise me at all, sgen was never meant to be used
with such massive
amount of memory, it was engineered to work well with much much less.

You can try the same benchmark with Java's or .NET's serial GCs and you'll
notice the same
ridiculous performance drop once you reach 50Gb of heap.

The way to improve it is to have a concurrent GC that would work in the
background, but this
is one lot of work. If you're interested you can hire someone to write it
and we would love to
integrate it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20111212/9ac6d36f/attachment.html