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

[matteo tesser]

Hi Rodrigo,

Yes, I release memory on finalizers (unfortunately I cannot use Disposable
objects). At the moment, I can provide you a binary test, if you can
reproduce the behavior, and it is needed, I can try to exact the relevant
code for the procedure and provide source code, but it takes time.

you can download the test here:

http://fairmat.com/tests/TestGC.tar.gz

and run
mono --gs=bohem TestGC.exe

the test in widows and osx uses constant memory, while in linux you should
obtain the following output:

# date: 233
# Maturity: 30
DSOP Initialize time:00:00:09.6344820
Live 186627 Live 349020 Live 490713 Live 549690 Live 579092 Live 691041 Live
832648 Live 978625 Live 1055648 Live 1233333 Live 1378727 Live 1586629 Live
1780660 Live 2035369 Live 2297367 Live 2504015 Live 2748390 Live 3004210
Live 3264366 Live 3508553 Live 3741829 Live 4015918 Live 4280187 Live
4524532 Live 4781589 Live 5041975 Live 5264760 Live 5529215 Live 5764582
Live 6026585 Live 6221326 Live 6460175 Live 6767039 Live 7014641 Live
7243492


the test program continue to evaluate  a function  and writes an estimation
of live instances every N evaluations, which are always increasing in this
case,

Thanks for looking at it,
Matteo



On Thu, Feb 17, 2011 at 8:13 PM, Rodrigo Kumpera <kumpera at gmail.com> wrote:

> Hi Matteo,
>
> I suppose you release memory on finalizers. Sgen has a longer cycle
> to finalize objects than boehm. On why extra retention is happening on
> linux is strange and could be a bug. Can you provide a test case that
> shows this behavior?
>
>
> On Fri, Feb 11, 2011 at 6:08 PM, matteo tesser <matteo.tesser at gmail.com>wrote:
>
>> 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
>> >>
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20110218/15e3f128/attachment.html