[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