0

I'm trying to understand how MT GC works to avoid memory leaks in iOS apps using (MonoTouch) MT.

As I understood (correct me if I'm wrong), MT memory management works in this manner: each object has a flag which says: "Dear GC, now I'm free to be released whenever you want". When the GC runs, it verifies that flag and remove the object from the memory. So, MT puts every object in a sort of limbo where objects in it will be released (next event cycle, maybe). It's a sort of autorealease mechanism. But it also possible to release explicity an object calling its dispose method. In this case, it means adopt retain-release mechanism.

Reading about MT, I've seen that there are objects that go into the managed heap (for example references to images) and other that go into unmanaged heap (for example images). In the first case (the managed one) I have not to be worry about it, the GC works well. In the second one (unmanaged case), I have to release memory explicity. Why this difference? Could you explain me how I can distinguish managed from unmanaged objects and when to release explicity the memory calling dispose method?

Thank you in advance.

Lorenzo B
  • 33,216
  • 24
  • 116
  • 190

1 Answers1

1

Your description is not quite right. Take the time to read Microsoft documentation about the GC (not GB ;-) and .NET, then read about Mono's current GC (and it's next version - even if it is not yet used for MonoTouch).

Once the above is clear you'll see the common problem when a small managed object can cause some problems (but not leaks) when it represent a large unmanaged object. Using IDisposable can solve this since it gives you more control when objects are finalized.

There's detailed documentation on how (and when) to use this.

poupou
  • 43,413
  • 6
  • 77
  • 174
  • Thank you! Can you explain the difference between managed and unmanaged objects? I've fixed GB mistake. Thanks. – Lorenzo B Aug 31 '11 at 13:53
  • 1
    The GC works only on the managed objects. But let's say I have a byte[1000000] array (managed), then the GC know it's a big object (and can use this knowledge). Now if I have a IntPtr (managed) object, that points to 1000000 (unmanaged) bytes, then the GC can only know it's 4/8 bytes (32/64bits). That's why you should implement (and/or use) IDisposable when dealing with IntPtr or unmanaged resources. Note that there can be non-memory related issues too (e.g. limit on the number of simultaneous open file handles, timers...) – poupou Aug 31 '11 at 14:03
  • Thanks! But how is it possible to distinguish between managed and unmanaged resources? IntPtr is a pointer to a XIB constructed interfaces. Unmanaged resources are images for example. Isn't true? – Lorenzo B Aug 31 '11 at 14:09
  • In MT, do I have to consider unmanaged objects those objects that I don't create explicity by code? – Lorenzo B Aug 31 '11 at 14:10
  • 1
    Just trust the API :-) i.e. if it implements IDisposable then try to Dispose them (e.g. 'using' statement) as soon as possible (to reclaim resources/memory) instead of waiting for the GC to collect them. IMO all other cases of trying to out[think|smart] the GC results in (much) more pain than any gain ;-) – poupou Aug 31 '11 at 14:18