[Mono-bugs] [Bug 435906] fatal errors in GC: too many heap sections

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=435906

User htl10 at users.sourceforge.net added comment
http://bugzilla.novell.com/show_bug.cgi?id=435906#c10





--- Comment #10 from Hin-Tak Leung <htl10 at users.sourceforge.net>  2009-04-27 21:18:03 MDT ---
(In reply to comment #6)
> How much memory does the application use?
> Which binary version of mono (and especially which version of the gc) are you
> using? The gc in mono has an increased number of heap sections that should
> cover
> memory use for more than 2 GB.
> If you compile mono you can increase them more by changing MAX_HEAP_SECTS in
> libgc/include/private/gc_priv.h.

I have jumped through some hoops to cross-compile mono (will be filling a few
bugs after that experience). I changed MAX_HEAP_SECTS to 4096 (the large-heap
value), and the application went a bit further before dying, so I went and
double it to 8192, and also change MAXHINCR to 4096 ; then the desired
operation runs to completion! 

I am running the win32 mono under wine on x86_64 linux - I need some p/invoke
gdi stuff. The curious thing is, top says mono.exe uses 3.6GB virtual, but
never go beyond 1.3G resident - without the recompile, the resident gradually
climbs from 300MB to 800/900MB then the error happens - I am on a machine with
a 2GB memory, so it works out fine. (the application does run under vista/.net
on the same hardware, so I know the hardware is capable). And mono also seems
to work a lot smoother after the recompile in that context.

Now, I have a question: what bad effect there might be if I increase those
numbers?

It seems that some application actually lies about usage and doesn't use what's
allocated? Is there a way of probing for the actual max values reached to see
how far off the default win32 mono build is?

This is on mono 2.4.

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.