Bug 9110 - Is the GREF limit too low?
Summary: Is the GREF limit too low?
Status: RESOLVED UPSTREAM
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.3.x
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-12-21 13:39 UTC by Stuart Lodge
Modified: 2012-12-21 14:09 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED UPSTREAM

Description Stuart Lodge 2012-12-21 13:39:12 UTC
I've had some interesting discussions with MvvmCross developers

One of them asked this question:

http://stackoverflow.com/questions/13842864/why-does-the-gref-go-too-high-when-i-put-a-mvxbindablespinner-in-a-mvxbindableli/

Another provided this sample: https://github.com/davidhauck/MvxSampleCode/

I believe that the core of both of these situations was that the apps were binding lists within lists (or even lists within lists within lists!)

I don't believe that this is necessarily good performant app design. 

I also acknowledge that the use of MvvmCross here has led to more view references being retained that could be achieved through hand-tuned code.

However, one thing that strikes me is that in the case of the DavidHauck sample, he took the code over to Java - and ran very similar code there with no problems.

The problem we saw in the MonoDroid version was that the GREF limit seemed to be causing lots of Garbage Collections to occur - which caused the app to run very slowly.

So I think there is a case here that the current limit on GREF numbers makes MonoDroid less performant than Java... which is obviously something I never want to say.

So

****

Is it possible to increase the GREF limit?

****

Note: apologies if I've got any of this wrong - it's taken a lot of investigation to get this far...
Comment 1 Stuart Lodge 2012-12-21 13:46:22 UTC
Update - just read the comment on stackoverflow from jonp - that the limit in GREFs comes from Droid, not from MonoDroid... thanks, didn't realise that... will keep thinking about how to avoid this situation...
Comment 2 Jonathan Pryor 2012-12-21 13:57:55 UTC
The limit varies: it's 2000 grefs for the emulator, and ~52000 for most hardware devices (except for a few badly configured devices...).

As Comment #1 mentions, this is a Dalvik-enforced limit, not a Mono for Android limit, so there's nothing we can do to "fix" this specific issue.

What we can do is migrate to an architecture that doesn't rely on grefs; this is (occasionally) being worked on, but such a drastic change will not be available any time soon.
Comment 3 Stuart Lodge 2012-12-21 14:09:00 UTC
Thanks Jonp

Writing down an answer is helping me understand more about what I still don't
understand.

I'm still not sure on this issue 

- because the numbers don't add up for me
- because the list scrolling shouldn't have any real effect

Both of these make me wonder if I'm not leaking something somewhere...

I'll have another go at debugging the GREF issue in the DavidHauck sample next
year - its just hard seeing 'wood for the trees' in those GREF traces from
Android

Thanks again for being a sounding board for the ideas - and for the info coming
back.

Stuart