[Mono-dev] sgen garbage collector/unmanaged resources/multi-thread issue

[matteo tesser]

Hi Rodrigo,
OK, taking or not taking into consideration memory pressure is a
runtime's implementation choice: if you consider memory pressure, the
runtime will be more reactive to memory usage, in the latter case no,
but unreferenced objects should be freed sooner or later.

I did an additional test: I counted the live object instances of the
object type which references the unmanaged resources over time: while
in windows and os x the live instances oscillate  between 10K and 60K,
 in  linux the live instances arrived to 20 milions. it seems that the
GC does not realize that so many objects  have been allocated. Are 20
milions objects  still a number that should not trigger the GC ?

Probably the problem is not related to unmanaged memory but the
particular structure of my problem highlights a defect.

Matteo



On Fri, Feb 11, 2011 at 3:34 PM, Rodrigo Kumpera <kumpera at gmail.com> wrote:
> Mono doesn't take memory pressure into account. This is probably
> what's happening.
> On Fri, Feb 11, 2011 at 3:54 PM, matteo tesser <matteo.tesser at gmail.com>
> wrote:
>>
>> Hello,
>>
>> I have a concurrent programming test  which during 5-10 minutes
>> creates and releases a  lot of objects which use unmanaged memory.
>> Every managed object,  respectively  allocates/deallocates the
>> unmanaged memory using  Marshal.AllocHGlobal and Marshall.FreeHGlobal
>> methods  and uses GC.AddMemoryPressure/GC.RemoveMemoryPressure to tell
>> to  the garbage collector the presence of the additional memory.
>>
>> I experienced some memory problems on linux,  so I did several tests:
>>
>>
>> 1)  In linux machine with openSuse 11.3 64bit dual core with  mono
>> 2.8.2,  the program launched with mono --gc=sgen eats 4GB of RAM in
>> about two minutes (see attached screenshot).
>> If I launch the test by specifying the use of  boehm gc,  the memory
>> is still consumed but at smaller rate.
>> I tried the test also with mono 2.10p3 and the behavior is the same
>> (also using MONO_GC_PARAMS=stack-mark=precise)
>>
>>
>> 2) In Windows/.NET the memory footprint  of the program is constant on
>> time:  80MB,
>> 3) in a dual core mac os x ( with mono 2.10p2) the behavior is the
>> same as windows.
>>
>> 4) In a Virtual Machine with  linux openSuse 11.3 32bit  and 1
>> processor  , mono 2.10p3 the test works fine: the memory footprint  is
>> constant at 50MB
>>
>> My conclusion is that the problem is restricted to the linux /
>> multi-thread case.
>> Are you aware of such issues on sgen?
>>
>> I tried to build-up a simple code reproducing the problem but I did
>> not managed to do it with a simple test case, in case are you
>> interested in a binary test case?
>>
>> Thanks,
>> Matteo
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>