[MonoTouch] Experimental reference counting - any progress?

[René Ruppert]

>This the the expected behavior most of the time. A garbage collection does
not release all memory after a collection as it's expected to be used

> shortly after and doing so would have a significant performance cost. What
happens is that it does shrink the heap if too much memory becomes
available.

 

But iOS‘ memory warnings are issued if that total block of memory allocated
through the app grows too much, even though the runtime only uses part of
it, correct?

This means that latest if the memory warning is fired, the amount of
allocated memory should drop significantly, because then GC should really
try to release as much as possible.

If that does not happen, do I have to assume, that my app has leaked (lots
of) memory, that cannot be reclaimed by GC/iOS, or could it be that now the
fragmentation hits my app?  Does SGen actually defragment?

I’m asking because I can sometimes see that the allocated memory (according
to Instruments) grows to some value around 200MB, then the memory warning is
received but memory usage won’t drop. Eventually, the app crashes. Memory
increases because of heavy use of web services. I’m not holding any
references.

I will still have a closer look with the memory profiler but first I would
like to understand the limitations of the GC to avoid hunting ghosts that I
cannot kill.

 

  

Ø  A Monotouch app require to load the mono runtime, create a managed heap
and load runtime metadata. Are those numbers with release or debug builds?

Ø  Debug builds have a much bigger footprint since nothing is stripped out.

Ø  The number for objc are that much smaller because most of the footprint
is hidden behind memory sharing with other processes.

 

The numbers are  lower with release builds. Compared to debug builds.

 

René

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/monotouch/attachments/20120322/166ae3ed/attachment-0001.html>