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 <kump...@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.tes...@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 <kump...@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.tes...@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@lists.ximian.com >> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> > >> > >> > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
