On Dec 16, 2011, at 9:43 AM, HSSoftware wrote:
> Attached is a reproducible case.
Thank you, that simplified investigations. :-)
> Is there something stupid I am doing, or is GC on a holiday?
The GC is on holiday. :-)
Well, not exactly. The problem here is that the GC has a limited view of memory
-- it only knows about the memory it's allocated. In the interest of being
performant, it doesn't want to perform collections that often, as collections
are slow. So collections are only performed when the GC thinks it's allocated
"enough" memory (subject to configuration, etc.).
The problem here is that Mono's GC doesn't know about memory allocated by the
Android GC, and thus Mono's GC doesn't know that a _ton_ of memory is being
kept alive by Mono; all Mono's GC sees is a lot of (comparatively small)
instances running around. Consider that for most managed objects, the only
instance data is a couple of IntPtrs (to hold the JNI handle value) -- sgen
thinks your Bitmap instance is only ~28 bytes in size, so you can allocate LOTS
of those before triggering a collection...
The short-term fix is to help the GC out, by overriding
ImageGridActivity.OnDestroy() and invoking GC.Collect():
protected override void OnDestroy ()
{
base.OnDestroy ();
GC.Collect ();
}
Once I do that, your test app stabilizes at ~255 global references on my Xoom.
The longer-term fix involves us adding GC.AddMemoryPressure() and
GC.RemoveMemoryPressure() support and some "glue" logic so that sgen "knows"
how big the Java-side bitmap actually is, and use that to modify how often
collections are performed. There's no ETA on this.
- Jon
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
