[Mono-dev] relaxing the 4GB heap limit (I think implied by LARGE_CONFIG) & bad out-of-memory behavior
Jonathan Shore
jonathan.shore at gmail.com
Thu Aug 30 00:32:53 UTC 2012
Ok, thanks. sgen fails for me for non-trivial programs (the VM crashes in 2.10.9 and 2.11.3 in different ways on both OSX and Linux). I'll post a bug report to bugzilla in a few.
On Aug 29, 2012, at 5:35 PM, Rodrigo Kumpera wrote:
> This is a limitation present on the Boehm collector. Either custom build it with a larger limit or switch to sgen.
>
>
> On Wed, Aug 29, 2012 at 6:05 PM, Jonathan Shore <jonathan.shore at gmail.com> wrote:
>
> I have applications that process through terrabytes of timeseries data. Usually I can limit the amount of memory I use in-process, however, from time to time I need to deal with data larger than 4GB in size. I run mono both on OSX and linux. It seems that the LARGE_CONFIG (which is not even the default), maxes out at something close to 4GB of heap. What would it take to relax this so can use more of a 64bit memory space?
>
> In libgc/include/private/gc_priv.h, there seems to be a hastable of heap pages, indexed by up to 20 bits in the LARGE_CONFIG compilation. The comment indicates that the 2097151 possible entries corresponds to roughly 4GB +/- of heap.
>
> Regardless of limitations build into the memory model, the mono runtime has the bad behavior of crashing when the maximum # of heap pages is reached instead of throwing OutOfMemoryException. Particularly for production services it would be useful to catch, say, a condition where most of the memory is used and throw an exception so that the application can exit or clean up gracefully.
>
> Thoughts on this?
>
> 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/20120829/c5765c30/attachment.html>
More information about the Mono-devel-list
mailing list