> > > With original list of ~100 items, I'm getting overflow with just a > couple of device (or emulator) "flips": > Is this with Mono for Android 4.0.6 or the 4.1.0 alpha? In 4.1.0 we > altered things so that when we hit a gref threshold we perform a collection > automatically. It's still not a great thing to rely on -- the GC might be > performed at the exact wrong time -- but could help with the gref limit. >
I haven't tried 4.1.0 yet, but I do GC.Collect(0) in each onStart. Will try using full GC.Collect Not necessarily; `aadapter.Dispose()` will allow the managed ArrayAdapter > to be collected (and free the associated gref), but it won't do anything > about what `aadapter` references (in this case `jl`, and everything it > contains). > > You're using the Android.Widget.ArrayAdapter(Context, int, IList) > constructor, which will construct a JavaList to contain the contents of the > IList, which will result in a gref for each element within the list. If > these are strings, it should be more efficient to instead use > ArrayAdapter<string>: > Why keeping these string grefs inside of M4A framework? I mean I've used an API method, which is actually a helper, because it does transformation of my .net list into java list. Why this helper leaves grefs from all the converted strings? imho it should invoke string.Dispose and not rely on GC. > > Is this a bug? Doing a workaround with: This workaround is the right idea, but wrong: given that you don't control > when collections are performed, it's possible that the Java.Lang.String you > create won't exist by the time you create the ArrayAdapter(). You should > instead have a second foreach loop to call js.Dispose() after the > ArrayAdapter constructor call. > Hm. Why? I've already added each string into the _java_ list. I don't care about string gref as soon as I've added it into java list, just because java list object will contain the reference to each java string! > I'll need to bump the priority of fixing scenarios like this... > Ok, thanks. > > Another, more annoying issue (no workaround found so far): > > Tried to remove listener delegates ( doing -=) but that doesn't help. > > #facepalm. Oops. Yeah, that's a definite bug. :-/ > > Doing also GC.Collect(0) in each onStart() - doesn't help. That's unexpected. Does a full GC.Collect() collect it? > Will try this. > > > I've already heard a comment "use real device and see no issues with > 50000 gref limit". > > But IMHO that is something like saying "get a 4Gb device and don't care > of these memory leaks". > > To a large degree, I agree. However, given the current model, if you have > a View that _requires_ holding > 2000 grefs, there's no way to make that > work on the emulator; hardware is the only workaround. (Can we change the > current gref-based model? Yes. Timeframe? Unknown... :-( > Agree, but I can't imagine the model where you need this amount of grefs instantly. grefs are just links between java and mono. As soon as I add and configure controls into the view - I need no more to keep grefs. Even in java I do not keep view object references, but use findViewById(). Moreover, in my case I have a real device with 2000gref limit (thats a bad device, I know, but still they exist on a market).
_______________________________________________ Monodroid mailing list [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
