Mono's GC

[TechSY730]

Based off of the GC errors, it still surprises me how badly Mono messed up at a macro level the GC in this version. I mean, how hard is this control flow?

1. Allocate memory for object. (If success, done)
1a. If not enough memory, run a GC (preferably a short one, though depending on the GC scheduling policy, it may be time for a mid or even full collection).
1b. If the heap is still at or near the current size of the heap, expand it, if there is still room to grow. If heap expansion was successful or not needed, retry step 1, else goto step 2
2. Retry allocation. (If success, done)
2b. If still not enough memory, run full GC
2c. Retry allocation. (If success, done)
2d. If still not enough memory, THEN throw an out of memory error.

Yes, this still does not account for when shrinking the heap may be desirable, nor does it quickly handle the case where a memory request is for more than the max heap size, but this policy is still FAR better than the policy Mono (whatever version Unity uses) uses.

Any word about when Unity plans to use the new version of Unity? IIRC, the latest versions of Mono have a decent GC and memory allocation policy. It doesn't seem like it should be too hard as long as they were sticking with the documented API, while avoiding deprecated calls and reliance on implementation specific details.

[x4000]

I presume that this error is actually on Unity 3D's side, in how they have chosen to implement the heap limitations.  Though, given the external-popup nature of the GC errors that are being thrown, those are clearly coming from inside the Mono runtime (the modal dialogs are a nice touch to put it into Daily WTF territory for unattended systems in particular).  So, I guess this is really a mix of an issue between Unity 3D and Mono, to my best guess, but I'm not certain.

On the new Mono GC, it's supposedly wicked, wicked good in terms of efficiency and so on.  BUT, it's also still in beta.  I can't imagine that Unity 3D is going to integrate it until it's out of beta.  Given that the first update to Mono in Unity was last year or so (before that they had been using a really ancient version of Mono since 2005), I'm not holding my breath for them to do this anytime soon.  And more to the point, Unity doesn't broadcast what their roadmap plans are for issues like this, nor do they even acknowledge the issue at all yet.  We have put it in their bugtracker, and even contacted their paid support about it, but got no response on either end.

[TechSY730]

Have you considered just tacking the newest version of Mono, instead of the one Unity provides? Or is there too many binary incompatible changes in the Mono library for that to work?

[x4000]

We thought about it, and even looked at it to some extent, but it's compiled right into the Unity platform, and there are too many changes for that to work smoothly.  A lot of the variables that would need to be set are inside the Unity DLLs themselves.  Back before AI War 4.0, that was something we looked at heavily.  But ultimately we wound up adjusting our programming practices to avoid things like foreach loops and to generally put less load on the heap, etc.  Mono has a number of heap-affecting things that are heap-static in .NET (like the foreach operator), so that had been an unpleasant surprise for us.

[TechSY730]

We thought about it, and even looked at it to some extent, but it's compiled right into the Unity platform

So Unity uses the mono API as a static library, huh? Stinks.

Wait, if it is statically linked, why did they include some of the Mono libraries in the managed folder as well? Or was that your doing?

[x4000]

Libraries != runtime.  The runtime itself is statically linked to my recollection (of course this was also unity 2.6, before their big 3.0 re-architecting).  But then the actual managed mono libraries they include in their managed folder.  To alter the GC behavior, that requires altering the mono runtime itself, not its runtime libraries.

[TechSY730]

Libraries != runtime.  The runtime itself is statically linked to my recollection (of course this was also unity 2.6, before their big 3.0 re-architecting).  But then the actual managed mono libraries they include in their managed folder.  To alter the GC behavior, that requires altering the mono runtime itself, not its runtime libraries.

Oh, that makes more sense. Thanks.

[x4000]

Yep!

[Hearteater]

Have you considered doing it all yourself without Unity at all?  With three games, and I'm assuming more in the future, at what point does it make sense to do it yourself since you'll be able to reuse your foundation again and again.

[x4000]

Have you considered doing it all yourself without Unity at all?  With three games, and I'm assuming more in the future, at what point does it make sense to do it yourself since you'll be able to reuse your foundation again and again.

Definitely not.  Prior to using Unity, I had a custom windows-only engine.  I have no desire to ever go that way again, for all the reasons we listed when we switched to unity in the first place, heh.