[Mono-dev] sgen garbage collector/unmanaged resources/multi-thread issue
matteo.tesser at gmail.com
Fri Feb 11 12:08:09 EST 2011
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.
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>
>> 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?
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list