[Mono-dev] relaxing the 4GB heap limit (I think implied by LARGE_CONFIG) & bad out-of-memory behavior

[Rodrigo Kumpera]

Reporting bugs is a good start. I noticed that Jonathan has an open bug
against sgen which we'll try to handle
before 2.12 final.


On Thu, Aug 30, 2012 at 2:13 AM, Greg Young <gregoryyoung1 at gmail.com> wrote:

> We have been experiencing crashes as well on large heaps. What can we do
> to help with this issue?
>
>
> On Thursday, August 30, 2012, Jonathan Shore wrote:
>
>> 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
>>>
>>>
>>
>>
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120830/5b652920/attachment.html>